Ответ 1

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

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

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

Ответ 2

А как насчет:

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

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

Ответ 3

Там действительно интересный раздел в Руководстве по обозревателям:

избегать.. /../../../../../..

Не все в приложении должным образом принадлежит общественности 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 с собственным полем преобразования в ваш каталог node_modules/foo или node_modules/app/fooпотому что преобразования не применяются по границам модулей. Это будет сделайте ваши модули более устойчивыми к изменениям конфигурации в вашем приложения, и будет проще самостоятельно повторно использовать пакеты вне вашего приложения.

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

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

ln -s ../lib node_modules/app

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

настраиваемые пути

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

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

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

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

Ответ 4

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

например:

- 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 найти его!

Как node_modules Работа

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

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

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

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

Для каждого существующего каталога xyz node сначала ищет 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 или no "main", предполагается index.js:

/beep/node_modules/xyz/index.js

Ответ 5

Общая картина

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

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

Существует много шумихи и контрудара вокруг Node.js. Но когда пыль оседает, мы признаем, что явные модули и "локальные первые" пакеты являются основным фактором принятия.

Общий случай

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

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

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

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

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

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

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

var express = require('./express')

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

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

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

Ответ 6

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

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

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

Ответ 7

IMHO, самый простой способ - определить свою собственную функцию как часть объекта 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');

<ч/" > @Totty, я придумал другое решение, которое могло бы работать для случая, описанного в комментариях. Описание gonna be tl;dr, поэтому лучше показать изображение с структурой моего тестового проекта.

Ответ 8

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

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

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

Ответ 9

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

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

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

Ответ 10

Здесь хорошо обсуждается этот вопрос здесь.

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

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

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

• 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');

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

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

Ответ 11

Если вы используете пряжу вместо 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')

Ответ 12

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

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

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

Ответ 13

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

Пример:

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

Ответ 14

В некоторых ответах говорится, что лучший способ - это добавить код к 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

Ответ 15

Вы можете определить что-то подобное в своем приложении app.js:

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

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

Ответ 16

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

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

Ответ 17

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

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

Впоследствии вы можете получить доступ к свойству всюду:

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

Ответ 18

Не может ли каталог 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').

Ответ 19

Другой ответ:

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

• 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 module:

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

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

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

Ответ 20

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

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

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

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

Итак, вот что.

Ответ 21

Мне нравится делать, как node загружается из каталога node_module для этого.

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

require('thing');

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

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

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

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

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

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

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

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

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

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

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

Ответ 22

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

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()

Ответ 23

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

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

Ответ 24

i создал модуль node, называемый "rekiure"

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

https://npmjs.org/package/rekuire

он очень прост в использовании

Ответ 25

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

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

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

Например

var context = {}

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

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

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);
    }
};

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

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

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

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

Позже мы также можем определить beans как функции, что позволит нам require разные модули в соответствии с окружением, но это из этой области потока.

Ответ 26

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

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

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

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

Ответ 27

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

npm install --save rootpath

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

require('rootpath')();

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

Ответ 28

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

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

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

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

global.appBasePath = __dirname;

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

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

Ответ 29

Просто хочу следить за отличным ответом от Paolo Moretti и Browserify. Если вы используете транспилятор (например, babel, typescript), и у вас есть отдельные папки для исходного кода и кода с расширением, например 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.

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

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

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

Оговорка с babel -copy-files Флаг --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

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

Ответ 30

Некоторое время назад я создал модуль для загрузки модулей относительно заранее определенных путей.

https://github.com/raaymax/irequire

Вы можете использовать его вместо требуемого.

irequire.prefix('controllers',join.path(__dirname,'app/master'));
var adminUsersCtrl = irequire("controllers:admin/users");
var net = irequire('net');

Может быть, это будет полезно для кого-то..