Как сделать так, чтобы node.js требовал абсолютного? (вместо относительного)

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

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

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

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

express = require('../')

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

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

Update 2

Теперь я использую require.js, который позволяет писать одним способом и работает как на клиенте, так и на сервере. Require.js также позволяет создавать собственные пути .- & # xAB;

Update 3

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

 zloctb26 мая 2016 г., 09:15
 steampowered11 июн. 2015 г., 20:33
Если вы когда-нибудь решите использовать явную корневую постоянную / переменную пути,this answer works for that, Решение использует крошечный модуль github для определения корневого пути.

Ответы на вопрос(30)

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

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()
 12 июл. 2017 г., 23:29
Это отлично сработало для простого проекта и намного проще, чем любой другой ответ.
 Totty.js03 мая 2017 г., 13:34
Иногда у меня есть личные пакеты в главном проекте, этот скрипт порвет с этим. В дополнение к этому я не уверен, что он будет нормально работать с webpack (в случае, если вы используете webpack с node.js, как я)
 03 мая 2017 г., 13:42
Если у вас есть вложенные каталоги с файлами пакетов, каждый каталог будет иметь возможность требовать только файлы в своем пакете. Это то поведение, которое вы хотите? Я не тестировался с веб-пакетом.

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

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

// require file relative to current working directory
config = require( path.resolve('.','config.js') );
 21 июл. 2015 г., 21:17
@cespon no, это просто относительно файла, который требуется.
 17 мая 2015 г., 22:29
config = require('./config.js'); действует тоже.

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

node_modules lodash src subdir foo.js bar.js main.js

tests

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

Теперь вы можете использоватьгалдеж истолпотворение-плагин-модуль-распознаватель с этим .babelrc файл для настройки 2 корневых папок:

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

Теперь вы можете запрашивать файлы таким же образом вtests И в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"
    ]
}

затем вы импортируете файлы вtests а такжеsrc как это :

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

yarn вместо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')
 25 февр. 2019 г., 19:08
Я немного отредактировал, чтобы уточнить. Извините за путаницу.
 25 февр. 2019 г., 14:46
Возможно, это идея прояснить, что этоonly works for yarnне для нпм? Я рассчитывал, что это, вероятно, будет работать и для npm, поэтому потратил немного времени на размышления о том, что я сделал неправильно, пока не попробовал использовать пряжу. Возможно, это было глупое предположение, но, возможно, я не единственный.

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

например:

- 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') и узел найдет это!

How node_modules Work

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

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

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

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

Для каждогоxyz каталог, который существует, узел сначала будет искать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
 30 сент. 2015 г., 19:26
отличное объяснение того, как это работает при загрузке модуля

отличный ответ от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

Используя 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

A caveat with 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 больше не будет видеть символические ссылки.

 Totty.js23 июн. 2017 г., 10:38
Спасибо, но я бы не рекомендовал делать это волшебство. Сначала вы потеряете весь импорт, он не будет рассчитываться вашей IDE. Если вы используете другие инструменты, такие как тип потока, он также не будет работать должным образом.
 24 июн. 2017 г., 21:08
На самом деле, поток работает в моем случае, что неудивительно, поскольку решения зависят от стандартной модели разрешения узлового узла и символических ссылок. Так что это не совсем волшебно для таких инструментов, как поток, чтобы понять. Но IDE разные.

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

Пример:

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

Справочник по Browserify:

avoiding ../../../../../../..

Not everything in an application properly belongs on the public npm and the overhead of setting up a private npm or git repo is still rather large in many cases. Here are some approaches for avoiding the ../../../../../../../ relative paths problem.

node_modules

People sometimes object to putting application-specific modules into node_modules because it is not obvious how to check in your internal modules without also checking in third-party modules from npm.

The answer is quite simple! If you have a .gitignore file that ignores node_modules:

node_modules

You can just add an exception with ! for each of your internal application modules:

node_modules/*
!node_modules/foo
!node_modules/bar

Please note that you can't unignore a subdirectory, if the parent is already ignored. So instead of ignoring node_modules, you have to ignore every directory inside node_modules with the node_modules/* trick, and then you can add your exceptions.

Now anywhere in your application you will be able to require('foo') or require('bar') without having a very large and fragile relative path.

If you have a lot of modules and want to keep them more separate from the third-party modules installed by npm, you can just put them all under a directory in node_modules such as node_modules/app:

node_modules/app/foo
node_modules/app/bar

Now you will be able to require('app/foo') or require('app/bar') from anywhere in your application.

In your .gitignore, just add an exception for node_modules/app:

node_modules/*
!node_modules/app

If your application had transforms configured in package.json, you'll need to create a separate package.json with its own transform field in your node_modules/foo or node_modules/app/foo component directory because transforms don't apply across module boundaries. This will make your modules more robust against configuration changes in your application and it will be easier to independently reuse the packages outside of your application.

symlink

Another handy trick if you are working on an application where you can make symlinks and don't need to support windows is to symlink a lib/ or app/ folder into node_modules. From the project root, do:

ln -s ../lib node_modules/app

and now from anywhere in your project you'll be able to require files in lib/ by doing require('app/foo.js') to get lib/foo.js.

custom paths

You might see some places talk about using the $NODE_PATH environment variable or opts.paths to add directories for node and browserify to look in to find modules.

Unlike most other platforms, using a shell-style array of path directories with $NODE_PATH is not as favorable in node compared to making effective use of the node_modules directory.

This is because your application is more tightly coupled to a runtime environment configuration so there are more moving parts and your application will only work when your environment is setup correctly.

node and browserify both support but discourage the use of $NODE_PATH.

 02 июл. 2015 г., 01:50
@Michael Не намного сложнее: git clean -dx node_modules
 Totty.js09 июл. 2014 г., 00:25
Спасибо (это удивительно. К счастью, мне это больше не нужно. Поскольку я делюсь кодом между клиентом и сервером, все мое приложение использует require.js, что позволяет намного проще создавать пути и не имеет узловых модулей). жестко закодированная переменная, которая была проблемой. Мне даже не нравится название, это должно быть как минимум nodeModules. В любом случае спасибо за удивительный ответ (:
 03 дек. 2015 г., 12:59
Или, если вы забылиgit clean синтаксис, всегда можноrm -rf node_modules && git checkout node_modules - обязательноgit stash в случае каких-либо изменений вnode_modules подкаталоги.
 21 дек. 2014 г., 15:15
Единственный недостаток положить его вnode_modules папка в том, что ее ядернее становится сложнее (rm -rf node_modules) папка
 25 янв. 2016 г., 21:49
Мне нравится идея использовать node_modules, но не для хранения исходного кода, учитывая, насколько он может быть изменчивым. Разве не имеет смысла публиковать отдельный модуль и сохранять его как зависимость в исходном проекте? Он обеспечивает четкое решение волатильности каталога node_modules и опирается только на npm, а не на git, символические ссылки или решение $ NODE_PATH.

поэтому я написал пакет под названиемвключают.

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

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

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

process.cwd() в моих проектах. Например:

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

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

что лучший способ - это добавить код к 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

 14 мар. 2017 г., 16:21
& quot; Эта функция полезна для локальной автономной разработки и создания тестов, которые требуют установки npm, если вы не хотите подключаться к внешнему серверу, но не должны использоваться при публикации пакетов в публичном реестре. & quot;

каталога node_module.

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

require('thing');

Затем узел будет искать «вещь» каталог в «узле_модуля»; каталог.

Поскольку 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';
 14 сент. 2018 г., 12:45
О вашей угловой ссылке, со стандартным приложением CLI, вы можете просто импортироватьsrc/app/my.serviceВы также можете настроить VSC для использования не относительного импорта для файлов машинописи.

Эта статья который упоминаетПриложение-модуль-путь, Это позволяет вам настроить базу следующим образом:

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

вот мой собственный вклад в эту работу:

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

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

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

Вот и все.

моего основного файла (например, index.js):

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

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

Вот.

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

mixing application modules with external dependencies or bothering with private npm repos for application-specific code using relative requires, which make refactoring and comprehension harder using symlinks or changing the node path, which can obscure source locations and don't play nicely with source control

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

npm-shrinkwrap.json package.json node_modules ... src 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');

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

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

 17 июл. 2014 г., 04:58
Исходя из сущности, которую вы связали, решение № 7 «Обертка» довольно простое и удобное.

Взяв примеры из других известных проектов, таких как spring и guice, мы определим «контекст»; объект, который будет содержать все "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.. 

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

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

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

https://npmjs.org/package/rekuire

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

 03 окт. 2018 г., 20:35
написание вредит моему мозгу. Но круто :)

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

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

 06 окт. 2014 г., 14:00
Если вы находите это слишком многословным, просто используйте .bind (): var rootReq = require.bind (require.main); rootReq («/ путь / к / модуль»);
 Totty.js07 окт. 2014 г., 12:35
да, это может быть полезно для тех, кто все еще хочет использовать browserify на стороне клиента. Для меня это больше не нужно, но все равно спасибо за ваш ответ (:
 03 нояб. 2016 г., 10:01
Это решение не будет работать, если код, покрытый модульными тестами, такими как тест Мокко
 16 апр. 2016 г., 02:35
ЕСЛИ ГЛАВНАЯ В КОРНИ ВАШЕГО ПРОЕКТА :)
 Totty.js03 окт. 2014 г., 16:41
Неплохая идея (: Затем вы можете определить некоторые другие методы, чтобы каким-то образом переназначить приложение в вашем модуле require.main. Я думаю, что вы могли бы затем сделать require.main.req (& quot; client / someMod & apos;). Хорошая идея, но это было бы более многословным, чем мои текущие requirejs. Также я не думаю, что это стоит, потому что я также не люблю browserify, потому что изменения не являются мгновенными и пропускают изменения (потому что мой код должен работать как в browser, так и в node.js).

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

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

 22 июл. 2013 г., 09:25
Спасибо! Я думаю, что это довольно умно и просто.
 17 окт. 2017 г., 08:47
сделал это давным-давно, вызывает боли при тестировании envs и тому подобное. не стоит накладных расходов. случайно новый глобальный делает новых людей неопределенными бла бла
 17 сент. 2014 г., 01:39
Прости меня отец, ибо я согрешил. Я перенес это на ES6 и получил следующее:requireFromRoot = ((root) => (resource) => require(`${root}/${resource}`))(__dirname);, Любите решение, но вам действительно нужно связывать __dirname так?
 17 сент. 2014 г., 17:39
Моя память немного запутана, но я считаю, что __dirname меняет значение в зависимости от того, в каком файле он используется. Теперь может случиться так, что поскольку функция определена в одном месте, но используется в нескольких местах, значение останется постоянным даже без этой привязки, но я просто сделал это, чтобы убедиться, что это действительно так.

самый простой способ - это определить свою собственную функцию как часть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, я предложил другое решение, которое могло бы подойти для случая, описанного вами в комментариях. Описание будетtl;drтак что я лучше покажу картинку сstructure of my test project.

 02 июн. 2012 г., 23:06
@ Тотти, зацениthis.
 Totty.js02 июн. 2012 г., 22:40
для не тестовых файлов:github.com/totty90/production01_server/blob/global-require/…в каждом тестовом файле:github.com/totty90/production01_server/blob/global-require/test/…
 Totty.js02 июн. 2012 г., 23:14
проблема возникает, когда я в "pathes-test / node_modules / other.js" & quot; и мне требуется & quot; pathes-test / node_modules / some.js & quot ;. Я должен требовать («/. Некоторые») вместо «требовать» («prj / некоторые»). И таким образом все мое приложение будет в директории node_modules?
 02 июн. 2012 г., 23:20
@ Тотти, не проблема, требующаяprj/some отprj/other (только что протестированоrequire('prj/some'). Все обычные модули приложения могут быть там (например, слой базы данных). Не имеет никакого значения, где, скажем,lib является. Попробуйте и посмотрите, подходит ли это.
 Totty.js02 июн. 2012 г., 22:26
ну, до сих пор это кажется лучшим способом сделать это. Я делаю: GLOBAL.requires = require ('r' a.). R; в моем файле index.js. Но у меня есть проблема в моих тестах на обеты, они не запускают index.js, поэтому мои тесты не пройдены, так как требует, чтобы он не был определен. В любом случае, сейчас я могу добавить GLOBAL.requires = require ('r' a.). R; в верхней части каждого теста. есть идея получше?github.com/totty90/production01_server/commit/…

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

npm install --save rootpath

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

require('rootpath')();

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

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

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

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

global.appBasePath = __dirname;

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

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

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

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

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

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

заданным путям.

https://github.com/raaymax/irequire

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

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

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

Решение Вопроса

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

node_modules myProject index.js I can require("myProject/someFolder/hey.js") instead of require("./someFolder/hey.js") someFolder which contains hey.js

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

 16 июн. 2014 г., 21:27
@cspiegl Вы можете использоватьNODE_PATH переменная окружения
 08 мая 2013 г., 15:23
Я использую аналогичный подход, за исключением того, что я добавляю локальный (проект)node_modules в/src, и уходи/node_modules для продавцов, чтобы держать вещи отдельно. Так что я/src/node_modules для местного кода и/node_modules для поставщиков.
 05 нояб. 2013 г., 19:56
ИМХО папка node_modules просто для node_modules. Не рекомендуется помещать весь проект в эту папку.
 17 янв. 2014 г., 13:23
@McSas, что бы вы предложили в качестве альтернативы, чтобы получить тот же эффект, что и выше?

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

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

 07 мая 2014 г., 22:01
Конечно, но Node.js в Windows не поддерживает символические ссылки по умолчанию.
 25 апр. 2014 г., 14:30
Обычно я бы не использовал этот шаблон для библиотеки (как большинство проектов с открытым исходным кодом). Тем не менее, можно создать эти символические ссылки в хуке сборки npm, поэтому пользователю не требуются глубокие знания.
 24 апр. 2014 г., 06:38
Поддержка в Windows требует более глубокого знания Node и ОС. Это может ограничить широкое использование проекта с открытым исходным кодом.
The big picture

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

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

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

The common case

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

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

Other workarounds

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

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

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

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

var express = require('./express')

examples/downloads/express.js

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

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

 17 окт. 2013 г., 17:03
& # x201C; Вы - второстепенные лидеры сообщества Node.js & # x201D; - Те же лидеры решили использовать обратные вызовы вместо фьючерсов / обещаний. Большинство моих консультаций по nodejs включают в себя проклятие упомянутых «лидеров» и убеждение людей перейти в JVM. Что намного проще после нескольких месяцев использования nodejs :)
 18 дек. 2015 г., 16:39
& quot; Вы - второстепенные лидеры сообщества Node.js & quot; пожалуйста, избегайте этого обескураживающего тона.
 27 февр. 2014 г., 14:21
@nirth, перейти на JVM? Ради бога, зачем?
 10 янв. 2016 г., 04:12
Черт возьми, он второй догадывающийся лидер узлов. Это то, как индустрия прогрессирует. Если бы парни из узла не догадывались о лидерах, которые поддерживали модели параллелизма на основе потоков, у нас не было бы узла.
 26 июл. 2013 г., 11:04
Я согласен с тем, что ребята из Node.js, по какой-то причине, выбрали относительное требование. Я просто не вижу его преимуществ ни из вашего ответа. Это все еще чувствует себя "плохо" мне ;)

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').

 Totty.js02 июн. 2012 г., 10:21
но с вашим примером мне нужно будет создать эти папки в каждой папке, где есть модуль, которому нужен метод require. В любом случае вам нужно позаботиться о времени & quot; ../& quot; в зависимости от папки.
 Totty.js02 июн. 2012 г., 10:17
да, извините за мою ошибку. требует (& APOS; проект / A & APOS;)
 02 июн. 2012 г., 11:00
На самом деле ссылка должна быть только вnode_modules Каталог в ближайшем родительском элементе файла и ссылка будут одинаковыми для обоих. Увидетьnodejs.org/api/…
 Totty.js02 июн. 2012 г., 10:01
Можете ли вы показать исходный код вашего теста, пожалуйста? хорошо, и это сработало бы, если бы мне пришлось требовать ('project.a') таким образом?
 02 июн. 2012 г., 10:15
Что вы подразумеваете подrequire('project.a')? Я думаю, что это может означатьrequire('project/a'), хотяrequire('project').a тоже возможно?

Узел-RFR.

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

var rfr = require('rfr');
var myModule = rfr('projectSubDir/myModule');
 19 мар. 2015 г., 03:34
Из документов: var module2 = rfr ("lib / module2"); // Начальная косая черта может быть опущена.
 23 окт. 2014 г., 15:32
я думаю, что вторая строка должна быть var myModule = rfr ("/ projectSubDir / myModule");
 22 авг. 2018 г., 05:23
Я попробовал это, и это rfr работает нормально, чтобы выполнить с узлом, но это нарушает навигацию по коду с VS Code ... Я не смог найти обходной путь, чтобы иметь возможность использовать автозаполнение в VS ...

Ваш ответ на вопрос