Я бы хотел, чтобы мои файлы всегда были в корне моего проекта, а не относительно текущего модуля.
Например, если вы посмотрите на 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/
Ответы:
И что насчет:
Он требует файл, как если бы он был необходим из основного файла js, поэтому он работает довольно хорошо, пока ваш основной файл js находится в корне вашего проекта ... и это то, что я ценю.
источник
В Руководстве Browserify есть действительно интересный раздел :
источник
node_modules
папку состоит в том, что она затрудняет работу с nuke (rm -rf node_modules
)git clean
синтаксис, всегда можноrm -rf node_modules && git checkout node_modules
- обязательноgit stash
в случае каких-либо изменений вnode_modules
подкаталогах.Я хотел бы создать новую
node_modules
папку для общего кода, затем позволить узлу и требовать делать то, что он делает лучше всего.например:
Например, если вы в
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
, узел ищет эти пути по порядку, останавливается при первом совпадении и выдает ошибку, если ничего не найдено:Для каждого
xyz
существующего каталога узел сначала будет искать a,xyz/package.json
чтобы увидеть, существует ли"main"
поле. В"main"
поле определяет , какой файл должен взять на себя ответственность , если вамrequire()
путь к каталогу.Например, если
/beep/node_modules/xyz
первое совпадение и/beep/node_modules/xyz/package.json
имеет:тогда экспорт из
/beep/node_modules/xyz/lib/abc.js
будет возвращенrequire('xyz')
.Если поля нет
package.json
или нет"main"
,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 (и многим другим нравится)
примеры / загрузки / express.js
Теперь, когда вы перемещаете эти файлы, наихудшим вариантом является исправление модуля с одним шимом .
источник
Посмотрите на node-rfr .
Это так просто, как это:
источник
Если вы используете пряжу вместо npm, вы можете использовать рабочие пространства .
Допустим, у меня есть папка, которую
services
я хочу более легко:Чтобы создать рабочую область Yarn, создайте
package.json
файл внутриservices folder
:В ваш основной package.json добавьте:
Запустите
yarn install
из корня проекта.Затем в любом месте вашего кода вы можете сделать:
вместо чего-то вроде:
источник
ИМХО, самый простой способ - определить собственную функцию как часть
GLOBAL
объекта. СоздайтеprojRequire.js
в корневом каталоге вашего проекта следующее содержимое:В вашем главном файле, прежде чем использовать
require
какой-либо из модулей, специфичных для проектаПосле этого у меня работает следующее:
@ Totty, я предложил другое решение, которое могло бы подойти для случая, описанного вами в комментариях. Описание будет
tl;dr
, поэтому я лучше покажу картинку со структурой моего тестового проекта .источник
prj/some
отprj/other
(только что протестированоrequire('prj/some'
). Все общие модули вашего приложения могут быть там (например, слой базы данных). Не имеет значения, где, скажем, вашlib
. Попробуйте и посмотрите, подходит ли это.Я использую
process.cwd()
в своих проектах. Например:Возможно, стоит отметить, что это приведет
require
к созданию абсолютного пути, хотя мне еще предстоит столкнуться с проблемами с этим.источник
Там хорошее обсуждение этого вопроса здесь .
Я столкнулся с той же архитектурной проблемой: я хотел, чтобы у моего приложения было больше организации и внутренних пространств имен, без:
В итоге я решил организовать свой код, используя соглашения об именах файлов, а не каталоги. Структура будет выглядеть примерно так:
Тогда в коде:
или просто
и внешние зависимости доступны из node_modules как обычно:
Таким образом, весь код приложения иерархически организован в модули и доступен для всего другого кода относительно корня приложения.
Конечно, основным недостатком является то, что в файловом браузере вы не можете развернуть / свернуть дерево, как будто оно фактически организовано в каталоги. Но мне нравится, что в нем очень четко указано, откуда исходит весь код, и он не использует никакой «магии».
источник
../x/x
которая уже читаема.Предполагая, что корнем вашего проекта является текущий рабочий каталог, это должно работать:
источник
config = require('./config.js');
действует тоже.Я перепробовал многие из этих решений. Я добавил это в начало моего основного файла (например, index.js):
Это добавляет корень проекта в NODE_PATH при загрузке скрипта. Позволяет мне требовать любой файл в моем проекте, ссылаясь на его относительный путь от корня проекта, например
var User = require('models/user')
. Это решение должно работать до тех пор, пока вы запускаете основной скрипт в корне проекта, прежде чем запускать что-либо еще в вашем проекте.источник
В некоторых ответах говорится, что лучший способ - это добавить код к node_module в виде пакета, я согласен, и, вероятно, это лучший способ потерять входящий запрос,
../../../
но ни один из них на самом деле не дает способа сделать это.с версии
2.0.0
вы можете установить пакет из локальных файлов, что означает, что вы можете создать папку в своем корне со всеми пакетами, которые вы хотите,поэтому в package.json вы можете добавить
modules
(илиfoo
иbar
) как пакет без публикации или использования внешнего сервера, например:После этого вы делаете
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 . В этом нет ничего сложного, просто помощник, так что вы можете с легкостью избежать этого точечного ада.
Пример:
источник
Вы можете определить что-то вроде этого в вашем app.js:
и затем в любое время, когда вы хотите что-то требовать от корня, независимо от того, где вы находитесь, вы просто используете requireFromRoot вместо ванильного требования. До сих пор у меня неплохо работает.
источник
requireFromRoot = ((root) => (resource) => require(`${root}/${resource}`))(__dirname);
. Любите решение, но вам действительно нужно связывать __dirname так?require
эта функция?Вот реальный способ, которым я занимаюсь больше 6 месяцев. Я использую папку с именем node_modules в качестве своей корневой папки в проекте, таким образом, она всегда будет искать эту папку везде, где я называю абсолютную потребность:
Это более полезно, когда вы вложены в папки, и гораздо меньше работы, чтобы изменить местоположение файла, если оно установлено абсолютно. Я использую только 2 относительных требования во всем приложении .
источник
node_modules
в систему/src
и оставляю/node_modules
продавцам отделять вещи. Так что я/src/node_modules
для местного кода и/node_modules
для поставщиков.NODE_PATH
переменную окруженияИмхо, самый простой способ добиться этого - создать символическую ссылку при запуске приложения в
node_modules/app
(или как вы это называете), на которую указывает../app
. Тогда вы можете просто позвонитьrequire("app/my/module")
. Символические ссылки доступны на всех основных платформах.Тем не менее, вы все равно должны разделить ваши вещи на более мелкие, обслуживаемые модули, которые устанавливаются через npm. Вы также можете установить свои приватные модули через git-url, поэтому нет причин иметь один монолитный каталог приложений.
источник
В вашем собственном проекте вы можете изменить любой файл .js, который используется в корневом каталоге, и добавить его путь к свойству
process.env
переменной. Например:После этого вы можете получить доступ к собственности везде:
источник
Еще один ответ:
Представьте себе эту структуру папок:
тесты
Затем в test.js вам нужны такие файлы:
и в main.js :
Теперь вы можете использовать babel и babel-plugin-module-resolver с этим. Файл babelrc для настройки 2 корневых папок:
Теперь вы можете одинаково запрашивать файлы в тестах и в src :
и если вы хотите использовать синтаксис модуля es6 :
затем вы импортируете файлы в тестах и src следующим образом:
источник
Только что натолкнулся на эту статью, в которой упоминается app-module-path . Это позволяет вам настроить базу следующим образом:
источник
Разве
examples
каталог не может содержатьnode_modules
символьную ссылку на корень проекта,project -> ../../
что позволяет использовать примерыrequire('project')
, хотя это не удаляет сопоставление, но позволяет использовать источник,require('project')
а неrequire('../../')
.Я проверил это, и он работает с v0.6.18.
Список
project
каталога:Содержимое
index.js
присваивает значение свойствуexports
объекта и вызываетconsole.log
сообщение, в котором говорится, что это было необходимо. Содержаниеtest.js
естьrequire('project')
.источник
require('project.a')
? Я думаю, что это может означатьrequire('project/a')
, хотяrequire('project').a
это также возможно?node_modules
каталоге в ближайшем родительском элементе файла, и тогда ссылка будет одинаковой для обоих. См. Nodejs.org/api/…project/node_modules/project -> ../
.Если кто-то ищет еще один способ обойти эту проблему, вот мой собственный вклад в эту работу:
Основная идея: вы создаете файл JSON в корне проекта, который отображает ваши пути к файлам с сокращенными именами (или заставляет use-automapper сделать это за вас). Затем вы можете запросить ваши файлы / модули, используя эти имена. Вот так:
Вот и все.
источник
Что мне нравится делать - это использовать для этого загрузку узла из каталога node_module.
Если кто-то попытается загрузить модуль «вещь», он будет делать что-то вроде
Затем Node будет искать каталог 'thing' в каталоге 'node_module'.
Поскольку node_module обычно находится в корне проекта, мы можем использовать эту согласованность. (Если node_module не находится в корне, то у вас есть другие самостоятельные головные боли, с которыми приходится иметь дело.)
Если мы войдем в каталог, а затем вернемся из него, мы сможем получить согласованный путь к корню проекта узла.
Затем, если мы хотим получить доступ к каталогу / happy, мы сделаем это.
Хотя это немного странно, но я чувствую, что если функциональность загрузки node_modules изменится, возникнут более серьезные проблемы. Такое поведение должно оставаться последовательным.
Чтобы прояснить ситуацию, я делаю это, потому что имя модуля не имеет значения.
Я использовал это недавно для angular2. Я хочу загрузить сервис из корня.
источник
src/app/my.service
также настроить VSC на использование относительного импорта для файлов машинописи.Я написал этот небольшой пакет, который позволяет вам запрашивать пакеты по их относительному пути от корня проекта, не вводя глобальных переменных и не переопределяя значения по умолчанию для узла
https://github.com/Gaafar/pkg-require
Работает так
источник
Просто хочу , чтобы следить за большой ответ от Paolo Moretti и Browserify. Если вы используете транспортер (например, babel, typcript) и у вас есть отдельные папки для исходного и переданного кода, такие как
src/
иdist/
, вы можете использовать различные варианты решений, например:node_modules
Со следующей структурой каталогов:
затем вы можете позволить babel и т. д. перенести
src
каталог вdist
каталог.символическая
Используя symlink, мы можем избавиться от некоторых уровней вложенности:
Протест с столпотворение --copy-файлы
--copy-files
флагbabel
не имеет дело с симлинками хорошо. Он может продолжать переходить по..
символической ссылке и рекурсивно видеть бесконечные файлы. Обходной путь должен использовать следующую структуру каталогов:Таким образом, код в under
src
будет по-прежнемуapp
разрешенsrc
, в то время как babel больше не будет видеть символические ссылки.источник
Я искал ту же самую простоту, чтобы требовать файлы любого уровня, и я нашел псевдоним модуля .
Просто установите:
Откройте файл package.json, здесь вы можете добавить псевдонимы для ваших путей, например,
И используйте ваши псевдонимы просто:
источник
я создал модуль узла под названием "rekiure"
это позволяет требовать без использования относительных путей
это супер легко использовать
источник
Мы собираемся попробовать новый способ решения этой проблемы.
Взяв примеры из других известных проектов, таких как spring и guice, мы определим объект «context», который будет содержать все операторы «require».
Этот объект будет затем передан всем другим модулям для использования.
Например
Это требует от нас написания каждого модуля как функции, которая получает опции, что в любом случае представляется нам наилучшей практикой.
и тогда вы будете ссылаться на контекст, а не требовать вещи.
var module1Ref = context.moduel1;
Если вы хотите, вы можете легко написать цикл для выполнения операторов require
Это должно облегчить жизнь, когда вы хотите использовать макеты (тесты), а также решить вашу проблему в процессе, делая ваш код многократно используемым как пакет.
Вы также можете повторно использовать код инициализации контекста, отделив от него объявление bean-компонентов. например, ваш
main.js
файл может выглядеть такЭтот метод также применим к внешним библиотекам, не нужно жестко кодировать их имена каждый раз, когда они нам нужны - однако он потребует особого подхода, поскольку их экспорт не является функциями, ожидающими контекст.
Позже мы также можем определить bean-компоненты как функции, которые позволят нам использовать
require
различные модули в соответствии с окружением, но это выходит за рамки этого потока.источник
У меня были проблемы с этой же проблемой, поэтому я написал пакет под названием include .
Включите дескрипторы, определяющие корневую папку вашего проекта путем поиска файла package.json, а затем передаете аргумент пути, который вы даете ему, в native require () без всякой путаницы относительного пути. Я представляю это не как замену require (), а как инструмент, требующий обработки неупакованных / сторонних файлов или библиотек. Что-то вроде
Я надеюсь, что это может быть полезно.
источник
Если js-файл точки входа вашего приложения (т. Е. Тот, в котором вы на самом деле запускаете «узел») находится в корневом каталоге вашего проекта, вы можете действительно легко это сделать с помощью модуля rootpath npm . Просто установите его через
... затем в самом верху js-файла точки входа добавьте:
С этого момента все требуемые вызовы теперь относятся к корню проекта - например,
require('../../../config/debugging/log');
становитсяrequire('config/debugging/log');
(где папка config находится в корне проекта).источник
В простых строках вы можете вызвать свою собственную папку как модуль:
Для этого нам понадобятся: глобальный и модуль app-module-path
здесь "App-module-path" - это модуль, он позволяет вам добавлять дополнительные каталоги к пути поиска модуля Node.js. И "global" - все, что вы прикрепляете к этому объекту, будет доступно везде в вашем приложении.
Теперь взгляните на этот фрагмент:
__dirname - текущий текущий каталог узла. Здесь вы можете указать свой собственный путь для поиска пути к модулю.
источник