Chciałbym wymagać moich plików zawsze od katalogu głównego mojego projektu, a nie od bieżącego modułu.

Na przykład, jeśli spojrzysz na https://github.com/visionmedia/express/blob/2820f2227de0229c5d7f28009aa432f9f3a7b5f9/examples/downloads/app.js wiersz 6 zobaczysz

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

To naprawdę złe IMO. Wyobraź sobie, że chciałbym umieścić wszystkie moje przykłady bliżej źródła tylko o jeden poziom. Byłoby to niemożliwe, ponieważ musiałbym aktualizować ponad 30 przykładów i wiele razy w każdym z nich. Do tego:

express = require('../')

Moim rozwiązaniem byłoby mieć specjalny przypadek oparty na katalogu głównym: jeśli ciąg zaczyna się od $, to jest względny w stosunku do folderu głównego projektu.

Jakakolwiek pomoc się przyda, dzięki

Aktualizacja 2

Teraz używam wymaganego.js, który pozwala pisać w jeden sposób i działa zarówno na kliencie, jak i na serwerze. Require.js pozwala także tworzyć niestandardowe ścieżki.

Aktualizacja 3

Teraz przeniosłem się na webpack + gulp i korzystam z rozszerzonego wymagania do obsługi modułów po stronie serwera. Zobacz tutaj uzasadnienie: http://hackhat.com/p/110/module-loader-webpack-vs-requirejs-vs-browserify/

A co z:

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

Wymaga pliku tak, jakby był wymagany z głównego pliku js, więc działa całkiem dobrze, dopóki główny plik js znajduje się w katalogu głównym projektu ... i to doceniam.

W Podręczniku Browserify znajduje się naprawdę interesująca sekcja :

unikanie ../../../../../../ ..

Nie wszystko w aplikacji poprawnie należy do publicznego npm, a narzut związany z konfiguracją prywatnego npm lub git repo jest wciąż dość duży w wielu przypadkach. Oto kilka podejść do unikania ../../../../../../../ problemu ścieżek względnych.

node_modules

Ludzie czasami sprzeciwiają się umieszczeniu modułów specyficznych dla aplikacji w module_węzła, ponieważ nie jest oczywiste, jak sprawdzić moduły wewnętrzne bez sprawdzania modułów innych firm z npm.

Odpowiedź jest dość prosta! Jeśli masz .gitignoreplik, który ignoruje node_modules:

node_modules

Możesz po prostu dodać wyjątek !dla każdego z wewnętrznych modułów aplikacji:

node_modules/*
!node_modules/foo
!node_modules/bar

Pamiętaj, że nie możesz anulować ignorowania podkatalogu, jeśli rodzic jest już ignorowany. Więc zamiast ignorując node_modules, trzeba ignorować każdym katalogu wnętrze node_modules z node_modules/* trik, a następnie można dodać wyjątki.

Teraz w dowolnym miejscu aplikacji będziesz mógł require('foo') lubrequire('bar') nie posiadające bardzo duży i kruchy ścieżkę względną.

Jeśli masz dużo modułów i chcesz je bardziej oddzielić od modułów innych firm zainstalowanych przez npm, możesz po prostu umieścić je wszystkie w katalogu, na node_modulesprzykład node_modules/app:

node_modules/app/foo
node_modules/app/bar

Teraz będziesz mógł require('app/foo')lubrequire('app/bar') z dowolnego miejsca w aplikacji.

W swoim .gitignoredodaj po prostu wyjątek dla node_modules/app:

node_modules/*
!node_modules/app

Jeśli aplikacja nie przekształca skonfigurowany w package.json, musisz utworzyć osobne package.json z własnym przekształcenia w swojej dziedzinie node_modules/foolubnode_modules/app/foo katalogu katalogu komponentów, ponieważ transformacje nie mają zastosowania poza granicami modułów. Dzięki temu Twoje moduły będą bardziej odporne na zmiany konfiguracji w aplikacji i łatwiej będzie samodzielnie używać pakietów poza aplikacją.

dowiązanie symboliczne

Inną przydatną sztuczką, jeśli pracujesz nad aplikacją, w której możesz tworzyć dowiązania symboliczne i nie potrzebujesz obsługiwać okien, jest dowiązanie symboliczne lib/ lub app/folder do node_modules. Z katalogu głównego projektu wykonaj:

ln -s ../lib node_modules/app

a teraz z dowolnego miejsca w swoim projekcie będziesz mógł wymagać plików lib/, wykonując require('app/foo.js')polecenie uzyskania lib/foo.js.

ścieżki niestandardowe

Możesz zobaczyć, że niektóre miejsca mówią o używaniu $NODE_PATH zmiennej środowiskowej lubopts.paths o dodaniu katalogów dla węzła i przeglądaniu w celu znalezienia modułów.

W przeciwieństwie do większości innych platform, korzystanie z tablicy katalogów ścieżek w stylu powłoki $NODE_PATHnie jest tak korzystne w węźle w porównaniu do efektywnego wykorzystania node_moduleskatalogu.

Wynika to z faktu, że aplikacja jest ściślej sprzężona z konfiguracją środowiska wykonawczego, więc jest więcej ruchomych części, a aplikacja będzie działać tylko wtedy, gdy środowisko zostanie poprawnie skonfigurowane.

węzeł i przeglądarka obsługują oba, ale odradzają korzystanie z nich $NODE_PATH.

Lubię utworzyć nowy node_modulesfolder dla wspólnego kodu, a następnie pozwolić, aby węzeł i wymagał robienia tego, co robi najlepiej.

na przykład:

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

Na przykład, jeśli jesteś w środku car/index.js, możesz require('helper')i węzeł go znajdzie!

Jak działają moduły_węzła

Węzeł ma sprytny algorytm rozwiązywania modułów, który jest unikalny wśród konkurencyjnych platform.

Jeśli require('./foo.js')z /beep/boop/bar.js, węzeł będzie szukał ./foo.jsw /beep/boop/foo.js. Ścieżki zaczynające się od ./lub ../zawsze są lokalne dla pliku, który wywołuje require().

Jeśli jednak potrzebujesz nie względnej nazwy, takiej jak require('xyz')from /beep/boop/foo.js, węzeł przeszukuje te ścieżki w kolejności, zatrzymując się przy pierwszym dopasowaniu i zgłaszając błąd, jeśli nic nie zostanie znalezione:

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

Dla każdego xyzistniejącego katalogu węzeł najpierw szuka znaku, xyz/package.jsonaby sprawdzić, czy "main"pole istnieje. Te "main"określa, który plik pola powinno przejąć Jeśli require()ścieżka katalogu.

Na przykład jeśli /beep/node_modules/xyzjest pierwszym dopasowaniem i /beep/node_modules/xyz/package.jsonma:

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

wówczas eksport z /beep/node_modules/xyz/lib/abc.jszostanie zwrócony przez require('xyz').

Jeśli nie package.jsonma "main"pola lub nie ma go , index.jsprzyjmuje się:

/beep/node_modules/xyz/index.js

Wielkie zdjęcie

Wydaje się „naprawdę zły”, ale daj mu czas. To jest naprawdę dobre. Te wyraźne require()zapewniają całkowitą przejrzystość i łatwość zrozumienia, która jest jak powiew świeżego powietrza podczas cyklu życia projektu.

Pomyśl o tym w ten sposób: czytasz przykład, zanurzając palce w Node.js i zdecydowałeś, że to „naprawdę zły IMO”. Jesteś drugim przywódcą społeczności Node.js, który zapisał więcej godzin na pisanie i utrzymywanie aplikacji Node.js niż ktokolwiek inny. Jaka jest szansa, że ​​autor popełnił taki debiutant? (I zgadzam się, z mojego środowiska Ruby i Python, na początku wydaje się to katastrofą.)

Wokół Node.js. jest dużo szumu i przeciwdziałania. Ale kiedy opadnie kurz, uznamy, że wyraźne moduły i pakiety „najpierw lokalne” były głównym motorem adopcji.

Wspólny przypadek

Oczywiście node_modulesz bieżącego katalogu przeszukiwany jest rodzic, a następnie dziadek, pradziadek itp. Więc pakietów zainstalowano już działa w ten sposób. Zwykle możesz to zrobić require("express")z dowolnego miejsca w projekcie i działa dobrze.

Jeśli zauważysz, że ładujesz wspólne pliki z katalogu głównego projektu (być może dlatego, że są to wspólne funkcje narzędziowe), to jest duża wskazówka, że ​​nadszedł czas, aby stworzyć pakiet. Pakiety są bardzo proste: przenieś swoje pliki node_modules/i umieść package.json tam. Voila! Wszystko w tej przestrzeni nazw jest dostępne z całego projektu. Pakiety to właściwy sposób na przeniesienie kodu do globalnej przestrzeni nazw.

Inne obejścia

Ja osobiście nie używam tych technik, ale one odpowiadają na twoje pytanie i oczywiście znasz swoją sytuację lepiej niż ja.

Możesz ustawić $NODE_PATHna katalog główny projektu. Ten katalog zostanie przeszukany, gdy Ty require().

Następnie możesz pójść na kompromis i wymagać wspólnego, lokalnego pliku ze wszystkich swoich przykładów. Ten wspólny plik po prostu ponownie eksportuje prawdziwy plik z katalogu dziadków.

przykłady / pliki do pobrania / app.js (i wiele innych podobnych)

var express = require('./express')

przykłady / pliki do pobrania / express.js

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

Teraz, gdy przenosisz te pliki, najgorszym przypadkiem jest naprawienie modułu z jedną podkładką dystansową .

Spójrz na node-rfr .

To takie proste:

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

Jeśli używasz przędzy zamiast npm , możesz użyć obszarów roboczych .

Powiedzmy, że mam folder, servicesktórego chciałbym łatwiej wymagać:

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

Aby utworzyć obszar roboczy Przędza, utwórz package.jsonplik w services folder:

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

W głównym pakiecie.json dodaj:

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

Uruchom yarn installz katalogu głównego projektu.

Następnie w dowolnym miejscu kodu możesz:

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

zamiast czegoś takiego:

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

IMHO, najprostszym sposobem jest zdefiniowanie własnej funkcji jako części GLOBALobiektu. Utwórz projRequire.jsw katalogu głównym swojego projektu z następującą zawartością:

var projectDir = __dirname;

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

W głównym pliku przed wprowadzeniem requiredowolnego modułu specyficznego dla projektu:

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

Potem działa dla mnie:

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

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

Używam process.cwd()w swoich projektach. Na przykład:

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

Warto zauważyć, że doprowadzi to do requirepowstania absolutnej ścieżki, chociaż nie mam jeszcze z tym problemów.

Jest to dobre omówienie tego problemu tutaj .

Zetknąłem się z tym samym problemem architektonicznym: chciałem zapewnić mojej aplikacji więcej organizacji i wewnętrznych przestrzeni nazw, bez:

• mieszanie modułów aplikacji z zewnętrznymi zależnościami lub kłopotanie się prywatnymi repozytoriami npm dla kodu specyficznego dla aplikacji
• stosowanie względnych wymagań, które utrudniają refaktoryzację i rozumienie
• używając dowiązań symbolicznych lub zmieniając ścieżkę węzła, co może zaciemniać lokalizacje źródeł i nie działa dobrze z kontrolą źródła

Ostatecznie zdecydowałem się uporządkować kod przy użyciu konwencji nazewnictwa plików, a nie katalogów. Struktura wyglądałaby mniej więcej tak:

• npm-shrinkwrap.json
• pakiet.json
• node_modules
  • ...
• src
  • app.js
  • app.config.js
  • app.models.bar.js
  • app.models.foo.js
  • app.web.js
  • app.web.routes.js
  • ...

Następnie w kodzie:

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

Lub tylko

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

a zależności zewnętrzne są dostępne jak zwykle z node_modules:

var express = require('express');

W ten sposób cały kod aplikacji jest hierarchicznie zorganizowany w moduły i dostępny dla wszystkich innych kodów względem katalogu głównego aplikacji.

Główną wadą jest oczywiście to, że w przeglądarce plików nie można rozwinąć / zwinąć drzewa, tak jakby było ono faktycznie zorganizowane w katalogach. Ale podoba mi się to, że jest bardzo jasne, skąd pochodzi cały kod i nie używa żadnej „magii”.

Zakładając, że katalog główny projektu jest bieżącym katalogiem roboczym, powinno to działać:

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

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

Wypróbowałem wiele z tych rozwiązań. Skończyło się na dodaniu tego na górze mojego głównego pliku (np. Index.js):

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

Dodaje to katalog główny projektu do NODE_PATH, gdy skrypt jest ładowany. Pozwala mi to wymagać dowolnego pliku w moim projekcie, odwołując się do jego ścieżki względnej z katalogu głównego projektu, np var User = require('models/user'). To rozwiązanie powinno działać tak długo, jak długo uruchamiasz główny skrypt w katalogu głównym projektu, zanim uruchomisz cokolwiek innego w swoim projekcie.

Niektóre odpowiedzi mówią, że najlepszym sposobem jest dodanie kodu do modułu node_module jako pakietu, zgadzam się i jest to prawdopodobnie najlepszy sposób na utratę ../../../wymaganego, ale żadna z nich tak naprawdę nie pozwala.

od wersji 2.0.0możesz zainstalować pakiet z plików lokalnych, co oznacza, że ​​możesz utworzyć folder w swoim katalogu głównym ze wszystkimi żądanymi pakietami,

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

więc w package.json możesz dodać modules(lub fooi bar) jako pakiet bez publikowania lub korzystania z zewnętrznego serwera w następujący sposób:

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

Następnie npm installmożesz uzyskać dostęp do kodu za pomocą var foo = require("foo"), podobnie jak w przypadku wszystkich innych pakietów.

więcej informacji można znaleźć tutaj:

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

a tutaj jak stworzyć pakiet:

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

Możesz użyć modułu, który stworzyłem, Undot . To nic zaawansowanego, tylko pomocnik, dzięki czemu możesz z łatwością uniknąć tych piekielnych kropek.

Przykład:

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

Możesz zdefiniować coś takiego w pliku app.js:

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

a następnie za każdym razem, gdy chcesz wymagać czegoś od katalogu głównego, bez względu na to, gdzie jesteś, po prostu użyj wymagaFragRoot zamiast wymagania waniliowego. Jak dotąd działa dla mnie całkiem dobrze.

Oto faktyczny sposób, w jaki działam przez ponad 6 miesięcy. Używam folderu o nazwie node_modules jako mojego folderu głównego w projekcie, w ten sposób zawsze będzie szukał tego folderu z dowolnego miejsca, które nazywam bezwzględnym wymaganiem:

• node_modules
  • mój projekt
    • index.js Mogę wymagać („myProject / someFolder / hey.js”) zamiast wymagać („./ someFolder / hey.js”)
    • someFolder, który zawiera hey.js

Jest to bardziej przydatne, gdy jesteś zagnieżdżony w folderach, a zmiana lokalizacji pliku jest znacznie mniejsza, jeśli jest ustawiona w sposób bezwzględny. Używam tylko 2 względne wymagania w całej mojej aplikacji .

Imho najłatwiejszym sposobem na osiągnięcie tego jest utworzenie symbolicznego linku przy uruchamianiu aplikacji w node_modules/app(lub jakkolwiek to nazwiesz), który wskazuje ../app. Następnie możesz po prostu zadzwonić require("app/my/module"). Łącza symboliczne są dostępne na wszystkich głównych platformach.

Jednak nadal powinieneś podzielić swoje rzeczy na mniejsze, łatwe do utrzymania moduły, które są instalowane przez npm. Możesz również zainstalować swoje prywatne moduły za pomocą git-url, więc nie ma powodu, aby mieć jeden, monolityczny katalog aplikacji.

W swoim projekcie możesz zmodyfikować dowolny plik .js używany w katalogu głównym i dodać jego ścieżkę do właściwości process.envzmiennej. Na przykład:

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

Następnie możesz uzyskać dostęp do nieruchomości wszędzie:

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

Inna odpowiedź:

Wyobraź sobie tę strukturę folderów:

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

• testy

  • test.js

Następnie w pliku test.js musisz wymagać plików takich jak ten:

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

i w main.js :

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

Teraz możesz w tym celu używać babel i babel-plugin-module-resolver . plik babelrc do skonfigurowania 2 folderów głównych:

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

Teraz możesz wymagać plików w ten sam sposób w testach i src :

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

a jeśli chcesz użyć składni modułu es6 :

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

następnie importujesz pliki w testach i src w następujący sposób:

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

Właśnie natknąłem się na ten artykuł, w którym wspomniano o ścieżce modułu aplikacji . Pozwala skonfigurować bazę taką jak ta:

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

Czy exampleskatalog nie może zawierać node_modulesdowiązania symbolicznego do katalogu głównego projektu, project -> ../../umożliwiając w ten sposób wykorzystanie przykładów require('project'), chociaż nie usuwa to mapowania, ale pozwala na użycie źródła require('project')zamiastrequire('../../') .

Przetestowałem to i działa z v0.6.18.

Lista projectkatalogu:

$ 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 -> ../../

Zawartość index.jsatrybutu przypisuje wartość do właściwości exportsobiektu i wywołuje console.logz komunikatem, że jest ona wymagana. Zawartość test.jsjest require('project').

Jeśli ktoś szuka innego sposobu na obejście tego problemu, oto mój wkład w wysiłek:

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

Podstawowy pomysł: tworzysz plik JSON w katalogu głównym projektu, który mapuje ścieżki plików na nazwy skrócone (lub użyj use-automapper, aby to zrobić za Ciebie). Następnie możesz poprosić o swoje pliki / moduły, używając tych nazw. Tak jak:

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

Więc to jest to.

W tym celu lubię wykorzystywać sposób, w jaki węzeł ładuje się z katalogu node_module.

Jeśli ktoś spróbuje załadować moduł „rzecz”, zrobiłby coś takiego

require('thing');

Węzeł następnie wyszuka katalog „thing” w katalogu „node_module”.

Ponieważ moduł node_modele zwykle znajduje się u podstaw projektu, możemy wykorzystać tę spójność. (Jeśli moduł_węzła nie jest u nasady, masz inne samozapalne bóle głowy, z którymi musisz sobie poradzić.)

Jeśli wejdziemy do katalogu, a następnie wycofamy się z niego, możemy uzyskać spójną ścieżkę do katalogu głównego projektu węzła.

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

Następnie, jeśli chcemy uzyskać dostęp do katalogu / happy, zrobilibyśmy to.

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

Chociaż jest to dość zuchwałe, czuję jednak, że jeśli zmieni się funkcjonalność sposobu wczytywania modułów node_moduł, będą większe problemy do rozwiązania. To zachowanie powinno pozostać spójne.

Aby to wyjaśnić, robię to, ponieważ nazwa modułu nie ma znaczenia.

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

Ostatnio użyłem go do angular2. Chcę załadować usługę z katalogu głównego.

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

Napisałem ten mały pakiet, który pozwala wymagać pakietów według ścieżki względnej z katalogu głównego projektu, bez wprowadzania żadnych zmiennych globalnych lub nadpisywania domyślnych wartości węzłów

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

Działa to w ten sposób

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

Po prostu chcą śledzić na wielkim odpowiedź od Paolo Moretti i Browserify. Jeśli używasz transpilatora (np. Babel, maszynopis) i masz osobne foldery na kod źródłowy i transpilowany, takie jak src/idist/ , możesz użyć różnych rozwiązań, takich jak

node_modules

Dzięki następującej strukturze katalogów:

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

możesz następnie pozwolić babel itp. na przeniesienie srckatalogu dodist katalogu.

dowiązanie symboliczne

Za pomocą dowiązania symbolicznego możemy pozbyć się niektórych poziomów zagnieżdżania:

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

Zastrzeżenie z babel --copy-Files--copy-files Flaga babelnie zajmuje się dowiązania dobrze. Może nawigować do ..dowiązania symbolicznego i odruchowo widzieć nieskończone pliki. Obejściem tego problemu jest użycie następującej struktury katalogów:

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

W ten sposób kod pod srcnadal będzie approzstrzygany src, podczas gdy babel nie będzie już widział dowiązań symbolicznych.

Szukałem dokładnie takiej samej prostoty wymagającej plików z dowolnego poziomu i znalazłem alias modułu .

Wystarczy zainstalować:

npm i --save module-alias

Otwórz plik package.json, tutaj możesz dodać aliasy do swoich ścieżek, np

"_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
}

I użyj swoich aliasów, po prostu:

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

stworzyłem moduł węzła o nazwie „rekiure”

pozwala to wymagać bez użycia ścieżek względnych

https://npmjs.org/package/rekuire

jest bardzo łatwy w użyciu

Za chwilę wypróbujemy nowy sposób rozwiązania tego problemu.

Biorąc przykłady z innych znanych projektów, takich jak spring i guice, zdefiniujemy obiekt „kontekstowy”, który będzie zawierał całą instrukcję „wymaganą”.

Ten obiekt zostanie następnie przekazany do wszystkich innych modułów do użycia.

Na przykład

var context = {}

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

Wymaga to od nas napisania każdego modułu jako funkcji, która odbiera opcje, co i tak jest dla nas najlepszą praktyką.

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

a wtedy odniesiesz się do kontekstu zamiast wymagać czegoś.

var module1Ref = context.moduel1;

Jeśli chcesz, możesz łatwo napisać pętlę, aby wykonać wymagane instrukcje

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

Powinno to ułatwić życie, gdy chcesz wyśmiewać (testy), a także rozwiązać swój problem po drodze, jednocześnie czyniąc kod wielokrotnego użytku jako pakiet.

Możesz także ponownie użyć kodu inicjalizacji kontekstu, oddzielając od niego deklarację bean. na przykład twój main.jsplik może tak wyglądać

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

Ta metoda ma również zastosowanie do bibliotek zewnętrznych, nie trzeba sztywno kodować ich nazw za każdym razem, gdy ich potrzebujemy - będzie to jednak wymagać specjalnego traktowania, ponieważ ich eksport nie jest funkcjami, które oczekują kontekstu.

Później możemy również zdefiniować komponenty bean jako funkcje - co pozwoli nam na requireróżne moduły w zależności od środowiska - ale poza zakresem tego wątku.

Miałem problem z tym samym problemem, więc napisałem pakiet o nazwie include .

Uwzględnij uchwyty określające folder główny projektu poprzez zlokalizowanie pliku package.json, a następnie przekazuje podany argument ścieżki do rodzimej metody wymagania () bez całego bałaganu ścieżki względnej. Wyobrażam sobie, że nie jest to zamiennik funkcji requ (), ale narzędzie do wymagania obsługi plików lub bibliotek spakowanych / innych firm. Coś jak

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

Mam nadzieję, że to może być przydatne.

Jeśli plik js punktu wejścia aplikacji (tj. Ten, na którym faktycznie uruchamiasz „węzeł”) znajduje się w katalogu głównym projektu, możesz to zrobić naprawdę łatwo za pomocą modułu npm rootpath . Po prostu zainstaluj go przez

npm install --save rootpath

... następnie na samej górze pliku js punktu wejścia dodaj:

require('rootpath')();

Od tego momentu wszystkie wymagane wywołania są teraz względne względem katalogu głównego projektu - np. require('../../../config/debugging/log'); Staje się require('config/debugging/log');(gdzie folder konfiguracji znajduje się w katalogu głównym projektu).

W prostych wierszach możesz wywołać własny folder jako moduł:

Do tego potrzebujemy: moduł globalny i moduł ścieżki aplikacji

tutaj „App-module-path” jest modułem, umożliwia dodanie dodatkowych katalogów do ścieżki wyszukiwania modułu Node.js. A „global” oznacza, że ​​wszystko, co dołączysz do tego obiektu, będzie dostępne wszędzie w Twojej aplikacji.

Teraz spójrz na ten fragment:

global.appBasePath = __dirname;

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

__nazwa_katalogu jest bieżącym katalogiem uruchomionym węzła. Możesz tutaj podać własną ścieżkę, aby wyszukać ścieżkę modułu.