Me gustaría solicitar mis archivos siempre por la raíz de mi proyecto y no en relación con el módulo actual.

Por ejemplo, si mira https://github.com/visionmedia/express/blob/2820f2227de0229c5d7f28009aa432f9f3a7b5f9/examples/downloads/app.js línea 6 verá

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

Eso es realmente malo OMI. Imagine que me gustaría poner todos mis ejemplos más cerca de la raíz solo en un nivel. Eso sería imposible, porque tendría que actualizar más de 30 ejemplos y muchas veces dentro de cada ejemplo. A esto:

express = require('../')

Mi solución sería tener un caso especial para raíz basada: si una cadena comienza con un $, entonces es relativa a la carpeta raíz del proyecto.

Cualquier ayuda es apreciada, gracias

Actualización 2

Ahora estoy usando require.js que le permite escribir de una manera y funciona tanto en el cliente como en el servidor. Require.js también te permite crear rutas personalizadas.

Actualización 3

Ahora me mudé a webpack + gulp y uso el requerimiento mejorado para manejar módulos en el lado del servidor. Vea aquí la justificación: http://hackhat.com/p/110/module-loader-webpack-vs-requirejs-vs-browserify/

Y que hay con:

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

Requiere el archivo como si fuera necesario desde el archivo js principal, por lo que funciona bastante bien siempre que su archivo js principal esté en la raíz de su proyecto ... y eso es algo que agradezco.

Hay una sección realmente interesante en el Manual de Browserify :

evitando ../../../../../../ ..

No todo en una aplicación pertenece adecuadamente al npm público y la sobrecarga de configurar un npm privado o un repositorio de git sigue siendo bastante grande en muchos casos. Aquí hay algunos enfoques para evitar el ../../../../../../../problema de las rutas relativas.

nodo_módulos

Las personas a veces se oponen a colocar módulos específicos de la aplicación en node_modules porque no es obvio cómo registrar sus módulos internos sin también registrar los módulos de terceros desde npm.

¡La respuesta es bastante simple! Si tiene un .gitignorearchivo que ignora node_modules:

node_modules

Simplemente puede agregar una excepción con !cada uno de sus módulos de aplicación internos:

node_modules/*
!node_modules/foo
!node_modules/bar

Tenga en cuenta que no puede ignorar un subdirectorio, si el padre ya se ignora. Entonces, en lugar de ignorar node_modules, debe ignorar cada directorio dentro node_modules con el node_modules/*truco, y luego puede agregar sus excepciones.

Ahora, en cualquier lugar de su aplicación, podrá require('foo') o require('bar')no tener una ruta relativa muy grande y frágil.

Si tiene muchos módulos y desea mantenerlos más separados de los módulos de terceros instalados por npm, puede colocarlos todos en un directorio node_modulescomo node_modules/app:

node_modules/app/foo
node_modules/app/bar

Ahora podrá require('app/foo')o require('app/bar') desde cualquier lugar de su aplicación.

En su .gitignore, simplemente agregue una excepción para node_modules/app:

node_modules/*
!node_modules/app

Si su aplicación tenía transformaciones configuradas en package.json, deberá crear un package.json separado con su propio campo de transformación en su directorio node_modules/fooo node_modules/app/foocomponente porque las transformaciones no se aplican a través de los límites del módulo. Esto hará que sus módulos sean más robustos frente a los cambios de configuración en su aplicación y será más fácil reutilizar de forma independiente los paquetes fuera de su aplicación.

enlace simbólico

Otro truco útil si está trabajando en una aplicación en la que puede crear enlaces simbólicos y no necesita admitir ventanas es vincular una lib/ o una app/carpeta node_modules. Desde la raíz del proyecto, haga:

ln -s ../lib node_modules/app

y ahora desde cualquier parte de su proyecto podrá solicitar archivos lib/haciendo require('app/foo.js')para obtener lib/foo.js.

caminos personalizados

Es posible que vea algunos lugares que hablan sobre el uso de la $NODE_PATH variable de entorno o opts.pathspara agregar directorios para el nodo y browserify para buscar módulos.

A diferencia de la mayoría de las otras plataformas, el uso de una matriz de directorios de ruta con estilo de shell $NODE_PATHno es tan favorable en el nodo en comparación con el uso efectivo del node_modulesdirectorio.

Esto se debe a que su aplicación está más estrechamente acoplada a una configuración de entorno de tiempo de ejecución, por lo que hay más partes móviles y su aplicación solo funcionará cuando su entorno esté configurado correctamente.

node y browserify son compatibles pero desalientan el uso de $NODE_PATH.

Me gusta hacer una nueva node_modulescarpeta para el código compartido, luego dejar que node y require hagan lo que mejor sabe hacer.

por ejemplo:

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

Por ejemplo, si estás dentro car/index.js, puedes require('helper')y el nodo lo encontrará.

Cómo funcionan los node_modules

El nodo tiene un algoritmo inteligente para resolver módulos que es único entre las plataformas rivales.

Si eres require('./foo.js')de /beep/boop/bar.js, el nodo buscará ./foo.jsen /beep/boop/foo.js. Las rutas que comienzan con ./o ../siempre son locales al archivo que llama require().

Sin embargo, si necesita un nombre no relativo como require('xyz')from /beep/boop/foo.js, el nodo busca estas rutas en orden, deteniéndose en la primera coincidencia y generando un error si no se encuentra nada:

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

Para cada xyzdirectorio que existe, el nodo primero buscará un xyz/package.jsonpara ver si "main"existe un campo. El "main"campo define qué archivo debe encargarse si require()la ruta del directorio.

Por ejemplo, si /beep/node_modules/xyzes el primer partido y /beep/node_modules/xyz/package.jsontiene:

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

entonces las exportaciones de /beep/node_modules/xyz/lib/abc.jsserán devueltas por require('xyz').

Si no hay package.jsono no hay "main"campo, index.jsse supone:

/beep/node_modules/xyz/index.js

El panorama

Parece "realmente malo" pero dale tiempo. Es, de hecho, realmente bueno. Los require()s explícitos brindan una total transparencia y facilidad de comprensión que es como un soplo de aire fresco durante el ciclo de vida de un proyecto.

Piénselo de esta manera: está leyendo un ejemplo, sumergiendo los dedos de los pies en Node.js y ha decidido que es "realmente una mala OMI". Ustedes son líderes dudosos de la comunidad Node.js, personas que han registrado más horas escribiendo y manteniendo aplicaciones Node.js que nadie. ¿Cuál es la posibilidad de que el autor haya cometido un error tan novato? (Y estoy de acuerdo, desde mi experiencia en Ruby y Python, al principio parece un desastre).

Hay muchas exageraciones y contra-exageraciones en torno a Node.js. Pero cuando el polvo se asiente, reconoceremos que los módulos explícitos y los paquetes "locales primero" fueron un importante impulsor de la adopción.

El caso comun

Por supuesto, node_modulesdesde el directorio actual, se busca el padre, el abuelo, el bisabuelo, etc. Entonces, los paquetes que ha instalado ya funcionan de esta manera. Por lo general, puede require("express")hacerlo desde cualquier parte de su proyecto y funciona bien.

Si se encuentra cargando archivos comunes desde la raíz de su proyecto (tal vez porque son funciones de utilidad comunes), entonces esa es una gran pista de que es hora de hacer un paquete. Los paquetes son muy simples: mueva sus archivos node_modules/y colóquelos package.json allí. Voila! Se puede acceder a todo en ese espacio de nombres desde todo su proyecto. Los paquetes son la forma correcta de llevar su código a un espacio de nombres global.

Otras soluciones

Yo personalmente no uso estas técnicas, pero sí responden a tu pregunta, y por supuesto conoces tu propia situación mejor que yo.

Puede configurar $NODE_PATHla raíz de su proyecto. Ese directorio se buscará cuando usted require().

A continuación, podría comprometer y requerir un archivo local común de todos sus ejemplos. Ese archivo común simplemente reexporta el archivo verdadero en el directorio de abuelos.

examples / downloads / app.js (y muchos otros como este)

var express = require('./express')

ejemplos / descargas / express.js

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

Ahora, cuando reubica esos archivos, el peor de los casos es arreglar el módulo de una cuña .

Echa un vistazo a node-rfr .

Es tan simple como esto:

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

Si usa hilo en lugar de npm , puede usar espacios de trabajo .

Digamos que tengo una carpeta servicesque deseo requerir más fácilmente:

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

Para crear un espacio de trabajo de Yarn, cree un package.jsonarchivo dentro de services folder:

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

En su paquete principal.json agregue:

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

Ejecutar yarn installdesde la raíz del proyecto.

Luego, en cualquier parte de su código, puede hacer:

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

en lugar de algo como:

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

En mi humilde opinión, la forma más fácil es definir su propia función como parte del GLOBALobjeto. Cree projRequire.jsen la raíz de su proyecto con los siguientes contenidos:

var projectDir = __dirname;

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

En su archivo principal antes de requireincorporar cualquiera de los módulos específicos del proyecto:

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

Después de eso, lo siguiente funciona para mí:

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

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

Yo uso process.cwd()en mis proyectos. Por ejemplo:

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

Vale la pena señalar que esto dará como resultado requireun camino absoluto, aunque aún no he tenido problemas con esto.

Hay una buena discusión sobre este tema aquí .

Me encontré con el mismo problema arquitectónico: querer una forma de darle a mi aplicación más organización y espacios de nombres internos, sin:

• mezclar módulos de aplicación con dependencias externas o molestarse con repositorios privados de npm para código específico de la aplicación
• utilizando requisitos relativos, que dificultan la refactorización y la comprensión
• usando enlaces simbólicos o cambiando la ruta del nodo, lo que puede oscurecer las ubicaciones de origen y no jugar bien con el control de origen

Al final, decidí organizar mi código usando convenciones de nomenclatura de archivos en lugar de directorios. Una estructura se vería algo así como:

• npm-shrinkwrap.json
• package.json
• nodo_módulos
  • ...
• src
  • app.js
  • app.config.js
  • app.models.bar.js
  • app.models.foo.js
  • app.web.js
  • app.web.routes.js
  • ...

Luego en código:

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

o solo

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

y dependencias externas están disponibles desde node_modules como de costumbre:

var express = require('express');

De esta manera, todo el código de la aplicación se organiza jerárquicamente en módulos y está disponible para todos los demás códigos relativos a la raíz de la aplicación.

La principal desventaja es, por supuesto, que en un explorador de archivos, no puede expandir / colapsar el árbol como si realmente estuviera organizado en directorios. Pero me gusta que sea muy explícito acerca de dónde proviene todo el código, y no usa ninguna 'magia'.

Suponiendo que la raíz de su proyecto es el directorio de trabajo actual, esto debería funcionar:

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

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

He probado muchas de estas soluciones. Terminé agregando esto a la parte superior de mi archivo principal (por ejemplo, index.js):

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

Esto agrega la raíz del proyecto a NODE_PATH cuando se carga el script. El me permite requerir cualquier archivo en mi proyecto haciendo referencia a su ruta relativa desde la raíz del proyecto como var User = require('models/user'). Esta solución debería funcionar siempre que esté ejecutando un script principal en la raíz del proyecto antes de ejecutar cualquier otra cosa en su proyecto.

Algunas de las respuestas dicen que la mejor manera es agregar el código al nodo_módulo como un paquete, estoy de acuerdo y es probablemente la mejor manera de perder el ../../../requerimiento, pero ninguno de ellos brinda una forma de hacerlo.

desde la versión 2.0.0, puede instalar un paquete desde archivos locales, lo que significa que puede crear una carpeta en su raíz con todos los paquetes que desee,

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

así que en package.json puede agregar modules(o fooy bar) como un paquete sin publicar o usar un servidor externo como este:

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

Después de eso, puede hacerlo npm install, y puede acceder al código con var foo = require("foo"), como lo hace con todos los demás paquetes.

Aquí se puede encontrar más información :

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

y aquí cómo crear un paquete:

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

Podrías usar un módulo que hice, Undot . No es nada avanzado, solo un ayudante para que puedas evitar esos infierno de puntos con simplicidad.

Ejemplo:

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

Podría definir algo como esto en su app.js:

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

y luego, cada vez que desee requerir algo de la raíz, sin importar dónde se encuentre, simplemente use requireFromRoot en lugar del require vanilla. Funciona bastante bien para mí hasta ahora.

Esta es la forma en que lo estoy haciendo durante más de 6 meses. Utilizo una carpeta llamada node_modules como mi carpeta raíz en el proyecto, de esta manera siempre buscará esa carpeta en todas partes que llamo un requerimiento absoluto:

• nodo_módulos
  • mi proyecto
    • index.js puedo requerir ("myProject / someFolder / hey.js") en lugar de require ("./ someFolder / hey.js")
    • someFolder que contiene hey.js

Esto es más útil cuando está anidado en carpetas y es mucho menos trabajo cambiar la ubicación de un archivo si está configurado de manera absoluta. Solo uso 2 los requisitos relativos en toda mi aplicación .

En mi opinión, la forma más fácil de lograr esto es mediante la creación de un enlace simbólico en el inicio de la aplicación node_modules/app(o como se llame) que apunta ../app. Entonces puedes simplemente llamar require("app/my/module"). Los enlaces simbólicos están disponibles en todas las plataformas principales.

Sin embargo, aún debe dividir sus cosas en módulos más pequeños y fáciles de mantener que se instalan a través de npm. También puede instalar sus módulos privados a través de git-url, por lo que no hay razón para tener un directorio de aplicaciones monolítico.

En su propio proyecto, puede modificar cualquier archivo .js que se use en el directorio raíz y agregar su ruta a una propiedad de la process.envvariable. Por ejemplo:

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

Luego puede acceder a la propiedad desde cualquier lugar:

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

Otra respuesta:

Imagina esta estructura de carpetas:

• nodo_módulos
  • lodash
• src
  • subdir
    • foo.js
    • bar.js
  • main.js

• pruebas

  • test.js

Luego, en test.js , debe requerir archivos como este:

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

y en main.js :

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

Ahora puede usar babel y babel-plugin-module-resolver con esto. archivo babelrc para configurar 2 carpetas raíz:

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

Ahora puede requerir archivos de la misma manera en pruebas y en src :

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

y si quieres usar la sintaxis del módulo es6 :

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

luego importas archivos en pruebas y src como este:

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

Acabo de encontrar este artículo que menciona app-module-path . Le permite configurar una base como esta:

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

No podría el examplesdirectorio de contener una node_modulescon un enlace simbólico a la raíz del proyecto project -> ../../permitiendo así que los ejemplos de uso require('project'), aunque esto no elimina el mapeo, sí permite a la fuente a utilizar require('project')en lugar de require('../../').

He probado esto y funciona con v0.6.18.

Listado de projectdirectorio:

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

El contenido de index.jsasigna un valor a una propiedad del exportsobjeto e invoca console.logcon un mensaje que indica que fue requerido. El contenido de test.jses require('project').

Si alguien está buscando otra forma de solucionar este problema, esta es mi propia contribución al esfuerzo:

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

La idea básica: crea un archivo JSON en la raíz del proyecto que asigna tus rutas de archivo a nombres abreviados (u obtienes use-automapper para que lo haga por ti). Luego puede solicitar sus archivos / módulos con esos nombres. Al igual que:

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

Entonces ahí está eso.

Lo que me gusta hacer es aprovechar cómo se carga el nodo desde el directorio node_module para esto.

Si uno intenta cargar la "cosa" del módulo, haría algo como

require('thing');

Node buscará el directorio 'thing' en el directorio 'node_module'.

Dado que node_module está normalmente en la raíz del proyecto, podemos aprovechar esta coherencia. (Si node_module no está en la raíz, entonces tiene que lidiar con otros dolores de cabeza autoinducidos).

Si entramos en el directorio y luego salimos de él, podemos obtener una ruta coherente a la raíz del proyecto de nodo.

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

Entonces, si queremos acceder al directorio / happy, haremos esto.

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

Aunque es bastante hacky, creo que si cambia la funcionalidad de la carga de node_modules, habrá problemas más grandes con los que lidiar. Este comportamiento debe permanecer consistente.

Para aclarar las cosas, hago esto, porque el nombre del módulo no importa.

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

Lo usé recientemente para angular2. Quiero cargar un servicio desde la raíz.

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

Escribí este pequeño paquete que le permite solicitar paquetes por su ruta relativa desde la raíz del proyecto, sin introducir ninguna variable global o anular los valores predeterminados del nodo

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

Funciona así

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

Solo quiero seguir la gran respuesta de Paolo Moretti y Browserify. Si está utilizando un transpilador (por ejemplo, babel, mecanografiado) y tiene carpetas separadas para el código fuente y el código transpilado como src/y dist/, podría usar una variación de las soluciones como

nodo_módulos

Con la siguiente estructura de directorios:

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

entonces puede dejar que babel, etc. transpile srcdirectorio a distdirectorio.

enlace simbólico

Con el enlace simbólico podemos eliminar algunos niveles de anidamiento:

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

Una advertencia con babel --copy-files La --copy-filesbandera de babelno trata bien los enlaces simbólicos. Puede seguir navegando en el ..enlace simbólico y ver recusivamente archivos interminables. Una solución alternativa es usar la siguiente estructura de directorios:

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

De esta manera, el código debajo srcaún se habrá appresuelto src, mientras que Babel ya no verá enlaces simbólicos.

Estaba buscando exactamente la misma simplicidad para requerir archivos de cualquier nivel y encontré un alias de módulo .

Solo instale:

npm i --save module-alias

Abra su archivo package.json, aquí puede agregar alias para sus rutas, por ejemplo

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

Y usa tus alias simplemente:

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

Creé un módulo de nodo llamado "rekiure"

le permite requerir sin el uso de rutas relativas

https://npmjs.org/package/rekuire

es super fácil de usar

Estamos a punto de probar una nueva forma de abordar este problema.

Tomando ejemplos de otros proyectos conocidos como spring y guice, definiremos un objeto de "contexto" que contendrá toda la declaración "require".

Este objeto se pasará a todos los demás módulos para su uso.

Por ejemplo

var context = {}

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

Esto requiere que escribamos cada módulo como una función que recibe opciones, lo que nos parece una mejor práctica de todos modos.

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

y luego te referirás al contexto en lugar de requerir cosas.

var module1Ref = context.moduel1;

Si lo desea, puede escribir fácilmente un bucle para hacer las declaraciones requeridas

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

Esto debería hacer la vida más fácil cuando quieres simular (pruebas) y también resuelve tu problema en el camino mientras haces que tu código sea reutilizable como un paquete.

También puede reutilizar el código de inicialización de contexto separando la declaración de beans. por ejemplo, su main.jsarchivo podría verse así

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

Este método también se aplica a bibliotecas externas, no es necesario codificar sus nombres cada vez que los requerimos; sin embargo, requerirá un tratamiento especial ya que sus exportaciones no son funciones que esperen contexto.

Más adelante también podemos definir beans como funciones, lo que nos permitirá requirediferentes módulos de acuerdo con el entorno, pero fuera del alcance de este hilo.

Estaba teniendo problemas con este mismo problema, así que escribí un paquete llamado include .

Incluya identificadores para averiguar la carpeta raíz de su proyecto a través de la ubicación de su archivo package.json, luego pase el argumento de ruta que le da al require nativo () sin todo el desorden de ruta relativo. Me imagino que esto no es un reemplazo de require (), sino una herramienta para requerir el manejo de archivos o bibliotecas no empaquetadas / de terceros. Algo como

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

Espero que esto pueda ser útil.

Si el archivo js del punto de entrada de su aplicación (es decir, en el que realmente ejecuta "nodo") está en el directorio raíz del proyecto, puede hacerlo realmente fácilmente con el módulo rootpath npm . Simplemente instálelo a través de

npm install --save rootpath

... luego, en la parte superior del archivo js del punto de entrada, agregue:

require('rootpath')();

A partir de ese momento, todas las llamadas requeridas ahora son relativas a la raíz del proyecto, por ejemplo, se require('../../../config/debugging/log'); convierte en require('config/debugging/log');(donde la carpeta de configuración está en la raíz del proyecto).

En líneas simples, puede llamar a su propia carpeta como módulo:

Para eso necesitamos: módulo global y de módulo de ruta de aplicación

aquí "App-module-path" es el módulo, le permite agregar directorios adicionales a la ruta de búsqueda del módulo Node.js Y "global" es que todo lo que adjunte a este objeto estará disponible en todas partes en su aplicación.

Ahora eche un vistazo a este fragmento:

global.appBasePath = __dirname;

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

__dirname es el directorio actual en ejecución del nodo. Puede dar su propia ruta aquí para buscar la ruta del módulo.