Я бы хотел, чтобы мои файлы всегда были в корне моего проекта, а не относительно текущего модуля.

Например, если вы посмотрите на https://github.com/visionmedia/express/blob/2820f2227de0229c5d7f28009aa432f9f3a7b5f9/examples/downloads/app.js строку 6, вы увидите

express = require('../../')

Это действительно плохое ИМО. Представьте, что я хотел бы поместить все мои примеры ближе к корню только на один уровень. Это было бы невозможно, потому что мне пришлось бы обновлять более 30 примеров и много раз в каждом примере. К этому:

express = require('../')

Мое решение состоит в том, чтобы иметь особый случай для основанного на root: если строка начинается с $, то это относительно корневой папки проекта.

Любая помощь приветствуется, спасибо

Обновление 2

Сейчас я использую require.js, который позволяет писать одним способом и работает как на клиенте, так и на сервере. Require.js также позволяет создавать собственные пути.

Обновление 3

Теперь я перешел на webpack + gulp и использую расширенные требования для обработки модулей на стороне сервера. Смотрите здесь обоснование: http://hackhat.com/p/110/module-loader-webpack-vs-requirejs-vs-browserify/

И что насчет:

var myModule = require.main.require('./path/to/module');

Он требует файл, как если бы он был необходим из основного файла js, поэтому он работает довольно хорошо, пока ваш основной файл js находится в корне вашего проекта ... и это то, что я ценю.

В Руководстве Browserify есть действительно интересный раздел :

избегая ../../../../../../ ..

Не все в приложении должным образом принадлежит общедоступному npm, и накладные расходы на настройку частного npm или git-репо все еще довольно велики во многих случаях. Вот несколько подходов, позволяющих избежать ../../../../../../../проблемы относительных путей.

node_modules

Иногда люди возражают против помещения модулей приложения в node_modules, потому что не очевидно, как проверять ваши внутренние модули без проверки сторонних модулей из npm.

Ответ довольно прост! Если у вас есть .gitignoreфайл, который игнорирует node_modules:

node_modules

Вы можете просто добавить исключение !для каждого из ваших внутренних модулей приложения:

node_modules/*
!node_modules/foo
!node_modules/bar

Обратите внимание, что вы не можете игнорировать подкаталог, если родительский объект уже проигнорирован. Таким образом, вместо игнорирования node_modules, вы должны игнорировать каждый каталог внутри node_modules с помощью node_modules/*хитрости, а затем вы можете добавить свои исключения.

Теперь в любом месте вашего приложения вы сможете иметь require('foo') или require('bar')не иметь очень большой и хрупкий относительный путь.

Если у вас много модулей и вы хотите, чтобы они были более отделены от сторонних модулей, установленных npm, вы можете просто поместить их все в каталог, node_modulesнапример node_modules/app:

node_modules/app/foo
node_modules/app/bar

Теперь вы сможете require('app/foo')или require('app/bar') из любого места в приложении.

В вашем .gitignore, просто добавьте исключение для node_modules/app:

node_modules/*
!node_modules/app

Если ваше приложение сконфигурировало преобразования в package.json, вам нужно создать отдельный package.json со своим собственным полем transform в вашем каталоге node_modules/fooили node_modules/app/fooкаталоге компонентов, потому что преобразования не применяются через границы модуля. Это сделает ваши модули более устойчивыми к изменениям конфигурации в вашем приложении, и будет проще самостоятельно повторно использовать пакеты за пределами вашего приложения.

символическая

Еще одна удобная уловка, если вы работаете с приложением, в котором вы можете создавать символические ссылки и вам не требуется поддержка окон, - это создать символическую ссылку на папку lib/ или app/папку node_modules. Из корня проекта выполните:

ln -s ../lib node_modules/app

и теперь из любой точки вашего проекта вы сможете запрашивать файлы lib/, выполняя процедуру require('app/foo.js')получения lib/foo.js.

пользовательские пути

Вы можете увидеть некоторые места, где говорится об использовании $NODE_PATH переменной окружения или opts.pathsо добавлении каталогов для узла и просмотра страниц для поиска модулей.

В отличие от большинства других платформ, использование массива каталогов путей в стиле оболочки $NODE_PATHне так выгодно в узле по сравнению с эффективным использованием node_modulesкаталога.

Это связано с тем, что ваше приложение более тесно связано с конфигурацией среды выполнения, поэтому имеется больше движущихся частей, и ваше приложение будет работать только при правильной настройке среды.

узел и browserify оба поддерживают, но препятствуют использованию $NODE_PATH.

Я хотел бы создать новую node_modulesпапку для общего кода, затем позволить узлу и требовать делать то, что он делает лучше всего.

например:

- node_modules // => these are loaded from your package.json
- app
  - node_modules // => add node-style modules
    - helper.js
  - models
    - user
    - car
- package.json
- .gitignore

Например, если вы в car/index.jsсостоянии, require('helper')и узел найдет его!

Как работают node_modules

У узла есть умный алгоритм разрешения модулей, который уникален среди конкурирующих платформ.

Если вы require('./foo.js')из /beep/boop/bar.js, узел будет искать ./foo.jsв /beep/boop/foo.js. Пути, начинающиеся с ./или ../всегда локальные для вызывающего файла require().

Однако, если вам требуется не относительное имя, например require('xyz')from /beep/boop/foo.js, узел ищет эти пути по порядку, останавливается при первом совпадении и выдает ошибку, если ничего не найдено:

/beep/boop/node_modules/xyz
/beep/node_modules/xyz
/node_modules/xyz

Для каждого xyzсуществующего каталога узел сначала будет искать a, xyz/package.jsonчтобы увидеть, существует ли "main"поле. В "main"поле определяет , какой файл должен взять на себя ответственность , если вам require()путь к каталогу.

Например, если /beep/node_modules/xyzпервое совпадение и /beep/node_modules/xyz/package.jsonимеет:

{
  "name": "xyz",
  "version": "1.2.3",
  "main": "lib/abc.js"
}

тогда экспорт из /beep/node_modules/xyz/lib/abc.jsбудет возвращен require('xyz').

Если поля нет package.jsonили нет "main", index.jsпредполагается:

/beep/node_modules/xyz/index.js

Большая картинка

Это кажется "действительно плохим", но дайте ему время. На самом деле это действительно хорошо. Явные require()s дают полную прозрачность и простоту понимания, что похоже на глоток свежего воздуха в течение жизненного цикла проекта.

Подумайте об этом так: вы читаете пример, погружая свои пальцы в Node.js, и вы решили, что это «действительно плохое ИМО». Вы - второстепенные лидеры сообщества Node.js, люди, которые записывают больше часов на написание и поддержку приложений Node.js, чем кто-либо. Какова вероятность того, что автор совершил такую ​​ошибку новичка? (И я согласен, из моего опыта работы с Ruby и Python это поначалу кажется катастрофой.)

Вокруг Node.js. есть много ажиотажа и контрафакта. Но когда пыль осядет, мы признаем, что явные модули и пакеты «сначала локальные» были основным фактором принятия.

Общий случай

Конечно, node_modulesиз текущего каталога, затем ищется родитель, потом дедушка, прадедушка и т. Д. Поэтому установленные вами пакеты уже работают таким образом. Обычно вы можете require("express")из любого места в вашем проекте, и он отлично работает.

Если вы обнаружите, что загружаете обычные файлы из корневого каталога вашего проекта (возможно, потому, что они являются общими служебными функциями), то это большая подсказка, что пришло время создать пакет. Пакеты очень просты: переместите свои файлы в node_modules/и поместите package.json туда. Вуаля! Все в этом пространстве имен доступно из всего вашего проекта. Пакеты - это правильный способ перевести ваш код в глобальное пространство имен.

Другие обходные пути

Я лично не использую эти методы, но они отвечают на ваш вопрос, и, конечно, вы знаете свою ситуацию лучше, чем я.

Вы можете установить $NODE_PATHв свой проект root. Этот каталог будет искать, когда вы require().

Далее вы можете пойти на компромисс и потребовать общий локальный файл из всех ваших примеров. Этот общий файл просто реэкспортирует настоящий файл в каталог дедушки.

examples / downloads / app.js (и многим другим нравится)

var express = require('./express')

примеры / загрузки / express.js

module.exports = require('../../')

Теперь, когда вы перемещаете эти файлы, наихудшим вариантом является исправление модуля с одним шимом .

Посмотрите на node-rfr .

Это так просто, как это:

var rfr = require('rfr');
var myModule = rfr('projectSubDir/myModule');

Если вы используете пряжу вместо npm, вы можете использовать рабочие пространства .

Допустим, у меня есть папка, которую servicesя хочу более легко:

.
├── app.js
├── node_modules
├── test
├── services
│   ├── foo
│   └── bar
└── package.json

Чтобы создать рабочую область Yarn, создайте package.jsonфайл внутри services folder:

{
  "name": "myservices",
  "version": "1.0.0"
}

В ваш основной package.json добавьте:

"private": true,
"workspaces": ["myservices"]

Запустите yarn installиз корня проекта.

Затем в любом месте вашего кода вы можете сделать:

const { myFunc } = require('myservices/foo')

вместо чего-то вроде:

const { myFunc } = require('../../../../../../services/foo')

ИМХО, самый простой способ - определить собственную функцию как часть GLOBALобъекта. Создайте projRequire.jsв корневом каталоге вашего проекта следующее содержимое:

var projectDir = __dirname;

module.exports = GLOBAL.projRequire = function(module) {
  return require(projectDir + module);
}

В вашем главном файле, прежде чем использовать requireкакой-либо из модулей, специфичных для проекта

// init projRequire
require('./projRequire');

После этого у меня работает следующее:

// main file
projRequire('/lib/lol');

// index.js at projectDir/lib/lol/index.js
console.log('Ok');

Я использую process.cwd()в своих проектах. Например:

var Foo = require(process.cwd() + '/common/foo.js');

Возможно, стоит отметить, что это приведет requireк созданию абсолютного пути, хотя мне еще предстоит столкнуться с проблемами с этим.

Там хорошее обсуждение этого вопроса здесь .

Я столкнулся с той же архитектурной проблемой: я хотел, чтобы у моего приложения было больше организации и внутренних пространств имен, без:

• смешивание модулей приложения с внешними зависимостями или работа с частными репозиториями npm для кода конкретного приложения
• использование относительных требований, которые затрудняют рефакторинг и понимание
• использование символических ссылок или изменение пути к узлу, которые могут скрывать исходные местоположения и плохо работать с управлением исходным кодом

В итоге я решил организовать свой код, используя соглашения об именах файлов, а не каталоги. Структура будет выглядеть примерно так:

• NPM-shrinkwrap.json
• package.json
• node_modules
  • ...
• ЦСИ
  • app.js
  • app.config.js
  • app.models.bar.js
  • app.models.foo.js
  • app.web.js
  • app.web.routes.js
  • ...

Тогда в коде:

var app_config = require('./app.config');
var app_models_foo = require('./app.models.foo');

или просто

var config = require('./app.config');
var foo = require('./app.models.foo');

и внешние зависимости доступны из node_modules как обычно:

var express = require('express');

Таким образом, весь код приложения иерархически организован в модули и доступен для всего другого кода относительно корня приложения.

Конечно, основным недостатком является то, что в файловом браузере вы не можете развернуть / свернуть дерево, как будто оно фактически организовано в каталоги. Но мне нравится, что в нем очень четко указано, откуда исходит весь код, и он не использует никакой «магии».

Предполагая, что корнем вашего проекта является текущий рабочий каталог, это должно работать:

// require built-in path module
path = require('path');

// require file relative to current working directory
config = require( path.resolve('.','config.js') );

Я перепробовал многие из этих решений. Я добавил это в начало моего основного файла (например, index.js):

process.env.NODE_PATH = __dirname;
require('module').Module._initPaths();

Это добавляет корень проекта в NODE_PATH при загрузке скрипта. Позволяет мне требовать любой файл в моем проекте, ссылаясь на его относительный путь от корня проекта, например var User = require('models/user'). Это решение должно работать до тех пор, пока вы запускаете основной скрипт в корне проекта, прежде чем запускать что-либо еще в вашем проекте.

В некоторых ответах говорится, что лучший способ - это добавить код к node_module в виде пакета, я согласен, и, вероятно, это лучший способ потерять входящий запрос, ../../../но ни один из них на самом деле не дает способа сделать это.

с версии 2.0.0вы можете установить пакет из локальных файлов, что означает, что вы можете создать папку в своем корне со всеми пакетами, которые вы хотите,

-modules
 --foo
 --bar 
-app.js
-package.json

поэтому в package.json вы можете добавить modules(или fooи bar) как пакет без публикации или использования внешнего сервера, например:

{
  "name": "baz",
  "dependencies": {
    "bar": "file: ./modules/bar",
    "foo": "file: ./modules/foo"
  }
}

После этого вы делаете npm install, и вы можете получить доступ к коду с помощью var foo = require("foo"), как вы делаете со всеми другими пакетами.

больше информации можно найти здесь:

https://docs.npmjs.com/files/package.json#local-paths

а вот как создать пакет:

https://docs.npmjs.com/getting-started/creating-node-modules

Вы можете использовать модуль, который я сделал, Undot . В этом нет ничего сложного, просто помощник, так что вы можете с легкостью избежать этого точечного ада.

Пример:

var undot = require('undot');
var User = undot('models/user');
var config = undot('config');
var test = undot('test/api/user/auth');

Вы можете определить что-то вроде этого в вашем app.js:

requireFromRoot = (function(root) {
    return function(resource) {
        return require(root+"/"+resource);
    }
})(__dirname);

и затем в любое время, когда вы хотите что-то требовать от корня, независимо от того, где вы находитесь, вы просто используете requireFromRoot вместо ванильного требования. До сих пор у меня неплохо работает.

Вот реальный способ, которым я занимаюсь больше 6 месяцев. Я использую папку с именем node_modules в качестве своей корневой папки в проекте, таким образом, она всегда будет искать эту папку везде, где я называю абсолютную потребность:

• node_modules
  • мой проект
    • index.js Я могу потребовать ("myProject / someFolder / hey.js") вместо require ("./ someFolder / hey.js")
    • someFolder, который содержит hey.js

Это более полезно, когда вы вложены в папки, и гораздо меньше работы, чтобы изменить местоположение файла, если оно установлено абсолютно. Я использую только 2 относительных требования во всем приложении .

Имхо, самый простой способ добиться этого - создать символическую ссылку при запуске приложения в node_modules/app(или как вы это называете), на которую указывает ../app. Тогда вы можете просто позвонить require("app/my/module"). Символические ссылки доступны на всех основных платформах.

Тем не менее, вы все равно должны разделить ваши вещи на более мелкие, обслуживаемые модули, которые устанавливаются через npm. Вы также можете установить свои приватные модули через git-url, поэтому нет причин иметь один монолитный каталог приложений.

В вашем собственном проекте вы можете изменить любой файл .js, который используется в корневом каталоге, и добавить его путь к свойству process.envпеременной. Например:

// in index.js
process.env.root = __dirname;

После этого вы можете получить доступ к собственности везде:

// in app.js
express = require(process.env.root);

Еще один ответ:

Представьте себе эту структуру папок:

• node_modules
  • lodash
• ЦСИ
  • подкаталог
    • foo.js
    • bar.js
  • main.js

• тесты

  • test.js

Затем в test.js вам нужны такие файлы:

const foo = require("../src/subdir/foo");
const bar = require("../src/subdir/bar");
const main = require("../src/main");
const _ = require("lodash");

и в main.js :

const foo = require("./subdir/foo");
const bar = require("./subdir/bar");
const _ = require("lodash");

Теперь вы можете использовать babel и babel-plugin-module-resolver с этим. Файл babelrc для настройки 2 корневых папок:

{
    "plugins": [
        ["module-resolver", {
            "root": ["./src", "./src/subdir"]
        }]
    ]
}

Теперь вы можете одинаково запрашивать файлы в тестах и в src :

const foo = require("foo");
const bar = require("bar");
const main = require("main");
const _ = require("lodash");

и если вы хотите использовать синтаксис модуля es6 :

{
    "plugins": [
        ["module-resolver", {
            "root": ["./src", "./src/subdir"]
        }],
        "transform-es2015-modules-commonjs"
    ]
}

затем вы импортируете файлы в тестах и src следующим образом:

import foo from "foo"
import bar from "bar"
import _ from "lodash"

Только что натолкнулся на эту статью, в которой упоминается app-module-path . Это позволяет вам настроить базу следующим образом:

require('app-module-path').addPath(baseDir);

Разве examplesкаталог не может содержать node_modulesсимвольную ссылку на корень проекта, project -> ../../что позволяет использовать примеры require('project'), хотя это не удаляет сопоставление, но позволяет использовать источник, require('project')а не require('../../').

Я проверил это, и он работает с v0.6.18.

Список projectкаталога:

$ ls -lR project
project:
drwxr-xr-x 3 user user 4096 2012-06-02 03:51 examples
-rw-r--r-- 1 user user   49 2012-06-02 03:51 index.js

project/examples:
drwxr-xr-x 2 user user 4096 2012-06-02 03:50 node_modules
-rw-r--r-- 1 user user   20 2012-06-02 03:51 test.js

project/examples/node_modules:
lrwxrwxrwx 1 user user 6 2012-06-02 03:50 project -> ../../

Содержимое index.jsприсваивает значение свойству exportsобъекта и вызывает console.logсообщение, в котором говорится, что это было необходимо. Содержание test.jsесть require('project').

Если кто-то ищет еще один способ обойти эту проблему, вот мой собственный вклад в эту работу:

https://www.npmjs.com/package/use-import

Основная идея: вы создаете файл JSON в корне проекта, который отображает ваши пути к файлам с сокращенными именами (или заставляет use-automapper сделать это за вас). Затем вы можете запросить ваши файлы / модули, используя эти имена. Вот так:

var use = require('use-import');
var MyClass = use('MyClass');

Вот и все.

Что мне нравится делать - это использовать для этого загрузку узла из каталога node_module.

Если кто-то попытается загрузить модуль «вещь», он будет делать что-то вроде

require('thing');

Затем Node будет искать каталог 'thing' в каталоге 'node_module'.

Поскольку node_module обычно находится в корне проекта, мы можем использовать эту согласованность. (Если node_module не находится в корне, то у вас есть другие самостоятельные головные боли, с которыми приходится иметь дело.)

Если мы войдем в каталог, а затем вернемся из него, мы сможем получить согласованный путь к корню проекта узла.

require('thing/../../');

Затем, если мы хотим получить доступ к каталогу / happy, мы сделаем это.

require('thing/../../happy');

Хотя это немного странно, но я чувствую, что если функциональность загрузки node_modules изменится, возникнут более серьезные проблемы. Такое поведение должно оставаться последовательным.

Чтобы прояснить ситуацию, я делаю это, потому что имя модуля не имеет значения.

require('root/../../happy');

Я использовал это недавно для angular2. Я хочу загрузить сервис из корня.

import {MyService} from 'root/../../app/services/http/my.service';

Я написал этот небольшой пакет, который позволяет вам запрашивать пакеты по их относительному пути от корня проекта, не вводя глобальных переменных и не переопределяя значения по умолчанию для узла

https://github.com/Gaafar/pkg-require

Работает так

// create an instance that will find the nearest parent dir containing package.json from your __dirname
const pkgRequire = require('pkg-require')(__dirname);

// require a file relative to the your package.json directory 
const foo = pkgRequire('foo/foo')

// get the absolute path for a file
const absolutePathToFoo = pkgRequire.resolve('foo/foo')

// get the absolute path to your root directory
const packageRootPath = pkgRequire.root()

Просто хочу , чтобы следить за большой ответ от Paolo Moretti и Browserify. Если вы используете транспортер (например, babel, typcript) и у вас есть отдельные папки для исходного и переданного кода, такие как src/и dist/, вы можете использовать различные варианты решений, например:

node_modules

Со следующей структурой каталогов:

app
  node_modules
    ... // normal npm dependencies for app
  src
    node_modules
      app
        ... // source code
  dist
    node_modules
      app
        ... // transpiled code

затем вы можете позволить babel и т. д. перенести srcкаталог в distкаталог.

символическая

Используя symlink, мы можем избавиться от некоторых уровней вложенности:

app
  node_modules
    ... // normal npm dependencies for app
  src
    node_modules
      app // symlinks to '..'
    ... // source code
  dist
    node_modules
      app // symlinks to '..'
    ... // transpiled code

Протест с столпотворение --copy-файлы--copy-files флаг babelне имеет дело с симлинками хорошо. Он может продолжать переходить по ..символической ссылке и рекурсивно видеть бесконечные файлы. Обходной путь должен использовать следующую структуру каталогов:

app
  node_modules
    app // symlink to '../src'
    ... // normal npm dependencies for app
  src
    ... // source code
  dist
    node_modules
      app // symlinks to '..'
    ... // transpiled code

Таким образом, код в under srcбудет по-прежнему appразрешен src, в то время как babel больше не будет видеть символические ссылки.

Я искал ту же самую простоту, чтобы требовать файлы любого уровня, и я нашел псевдоним модуля .

Просто установите:

npm i --save module-alias

Откройте файл package.json, здесь вы можете добавить псевдонимы для ваших путей, например,

"_moduleAliases": {
 "@root"      : ".", // Application's root
 "@deep"      : "src/some/very/deep/directory/or/file",
 "@my_module" : "lib/some-file.js",
 "something"  : "src/foo", // Or without @. Actually, it could be any string
}

И используйте ваши псевдонимы просто:

require('module-alias/register')
const deep = require('@deep')
const module = require('something')

я создал модуль узла под названием "rekiure"

это позволяет требовать без использования относительных путей

https://npmjs.org/package/rekuire

это супер легко использовать

Мы собираемся попробовать новый способ решения этой проблемы.

Взяв примеры из других известных проектов, таких как spring и guice, мы определим объект «context», который будет содержать все операторы «require».

Этот объект будет затем передан всем другим модулям для использования.

Например

var context = {}

context.module1 = require("./module1")( { "context" : context } )
context.module2 = require("./module2")( { "context" : context } )

Это требует от нас написания каждого модуля как функции, которая получает опции, что в любом случае представляется нам наилучшей практикой.

module.exports = function(context){ ... }

и тогда вы будете ссылаться на контекст, а не требовать вещи.

var module1Ref = context.moduel1;

Если вы хотите, вы можете легко написать цикл для выполнения операторов require

var context = {};
var beans = {"module1" : "./module1","module2" : "./module2" }; 
for ( var i in beans ){
    if ( beans.hasOwnProperty(i)){
         context[i] = require(beans[i])(context);
    }
};

Это должно облегчить жизнь, когда вы хотите использовать макеты (тесты), а также решить вашу проблему в процессе, делая ваш код многократно используемым как пакет.

Вы также можете повторно использовать код инициализации контекста, отделив от него объявление bean-компонентов. например, ваш main.jsфайл может выглядеть так

var beans = { ... }; // like before
var context = require("context")(beans); // this example assumes context is a node_module since it is reused.. 

Этот метод также применим к внешним библиотекам, не нужно жестко кодировать их имена каждый раз, когда они нам нужны - однако он потребует особого подхода, поскольку их экспорт не является функциями, ожидающими контекст.

Позже мы также можем определить bean-компоненты как функции, которые позволят нам использовать requireразличные модули в соответствии с окружением, но это выходит за рамки этого потока.

У меня были проблемы с этой же проблемой, поэтому я написал пакет под названием include .

Включите дескрипторы, определяющие корневую папку вашего проекта путем поиска файла package.json, а затем передаете аргумент пути, который вы даете ему, в native require () без всякой путаницы относительного пути. Я представляю это не как замену require (), а как инструмент, требующий обработки неупакованных / сторонних файлов или библиотек. Что-то вроде

var async = require('async'),
    foo   = include('lib/path/to/foo')

Я надеюсь, что это может быть полезно.

Если js-файл точки входа вашего приложения (т. Е. Тот, в котором вы на самом деле запускаете «узел») находится в корневом каталоге вашего проекта, вы можете действительно легко это сделать с помощью модуля rootpath npm . Просто установите его через

npm install --save rootpath

... затем в самом верху js-файла точки входа добавьте:

require('rootpath')();

С этого момента все требуемые вызовы теперь относятся к корню проекта - например, require('../../../config/debugging/log'); становится require('config/debugging/log');(где папка config находится в корне проекта).

В простых строках вы можете вызвать свою собственную папку как модуль:

Для этого нам понадобятся: глобальный и модуль app-module-path

здесь "App-module-path" - это модуль, он позволяет вам добавлять дополнительные каталоги к пути поиска модуля Node.js. И "global" - все, что вы прикрепляете к этому объекту, будет доступно везде в вашем приложении.

Теперь взгляните на этот фрагмент:

global.appBasePath = __dirname;

require('app-module-path').addPath(appBasePath);

__dirname - текущий текущий каталог узла. Здесь вы можете указать свой собственный путь для поиска пути к модулю.