Esiste un modo migliore di process.cwd()determinare la directory principale di un processo node.js in esecuzione? Qualcosa come l'equivalente di Rails.root, ma per Node.js. Sto cercando qualcosa che sia il più prevedibile e affidabile possibile.

Esistono diversi modi per affrontarlo, ognuno con i propri pro e contro:

require.main.filename

Da http://nodejs.org/api/modules.html :

Quando un file viene eseguito direttamente dal nodo, require.mainviene impostato su relativo module. Ciò significa che è possibile determinare se un file è stato eseguito direttamente mediante testrequire.main === module

Poiché modulefornisce una filenameproprietà (normalmente equivalente a __filename), il punto di ingresso dell'applicazione corrente può essere ottenuto controllando require.main.filename.

Quindi, se vuoi la directory di base per la tua app, puoi fare:

var path = require('path');
var appDir = path.dirname(require.main.filename);

Pro e contro

Funzionerà alla grande per la maggior parte del tempo, ma se stai eseguendo la tua app con un launcher come pm2 o eseguendo test moka , questo metodo fallirà.

global.X

Il nodo ha un oggetto dello spazio dei nomi globale chiamato global: tutto ciò che si collega a questo oggetto sarà disponibile ovunque nell'app. Quindi, nel tuo index.js(o app.jscome si chiama il tuo file principale dell'app), puoi semplicemente definire una variabile globale:

// index.js
var path = require('path');
global.appRoot = path.resolve(__dirname);

// lib/moduleA/component1.js
require(appRoot + '/lib/moduleB/component2.js');

Pro e contro

Funziona costantemente ma devi fare affidamento su una variabile globale, il che significa che non puoi riutilizzare facilmente componenti / ecc.

process.cwd ()

Ciò restituisce la directory di lavoro corrente. Non affidabile a tutti, come è del tutto dipende da ciò che directory il processo è stato avviato da :

$ cd /home/demo/
$ mkdir subdir
$ echo "console.log(process.cwd());" > subdir/demo.js
$ node subdir/demo.js
/home/demo
$ cd subdir
$ node demo.js
/home/demo/subdir

app-root-path

Per risolvere questo problema, ho creato un modulo nodo chiamato app-root-path . L'uso è semplice:

var appRoot = require('app-root-path');
var myModule = require(appRoot + '/lib/my-module.js');

Il modulo percorso root dell'app utilizza diverse tecniche per determinare il percorso root dell'app, tenendo conto dei moduli installati a livello globale (ad esempio, se l'app è in esecuzione /var/www/ma il modulo è installato ~/.nvm/v0.x.x/lib/node/). Non funzionerà al 100% delle volte, ma funzionerà negli scenari più comuni.

Pro e contro

Funziona senza configurazione nella maggior parte dei casi. Fornisce inoltre alcuni metodi utili aggiuntivi (vedi la pagina del progetto). Il più grande svantaggio è che non funzionerà se:

• Stai usando un launcher, come pm2
• E , il modulo non è installato nella node_modulesdirectory della tua app (ad esempio, se lo hai installato a livello globale)

Puoi aggirare il problema impostando una APP_ROOT_PATHvariabile ambientale o chiamando .setPath()il modulo, ma in tal caso probabilmente stai meglio usando il globalmetodo.

NODE_PATH variabile ambientale

Se stai cercando un modo per determinare il percorso principale dell'app corrente, è probabile che una delle soluzioni di cui sopra funzioni meglio per te. Se, d'altra parte, stai cercando di risolvere il problema del caricamento affidabile dei moduli dell'app, ti consiglio vivamente di esaminare la NODE_PATHvariabile ambientale.

Il sistema di moduli Node cerca moduli in una varietà di posizioni. Una di queste posizioni è ovunque process.env.NODE_PATHpunti . Se imposti questa variabile ambientale, puoi requiremoduli con il caricatore di moduli standard senza altre modifiche.

Ad esempio, se si imposta NODE_PATHsu /var/www/lib, il seguente funzionerebbe perfettamente:

require('module2/component.js');
// ^ looks for /var/www/lib/module2/component.js

Un ottimo modo per farlo è usare npm:

"scripts": {
    "start": "NODE_PATH=. node app.js"
}

Ora puoi avviare la tua app con npm starte sei d'oro. Unisco questo con il mio modulo enforce-node-path , che impedisce il caricamento accidentale dell'app senza NODE_PATHimpostazione. Per un controllo ancora maggiore sull'applicazione delle variabili ambientali, vedere checkenv .

One gotcha: NODE_PATH deve essere impostato al di fuori dell'app del nodo. Non puoi fare qualcosa del genere process.env.NODE_PATH = path.resolve(__dirname)perché il caricatore di moduli memorizza nella cache l'elenco delle directory che cercherà prima dell'esecuzione dell'app.

[aggiunto il 6/6/16] Un altro modulo davvero promettente che tenta di risolvere questo problema è ondulato .

__dirnamenon è un globale; è locale al modulo corrente, quindi ogni file ha il suo valore locale diverso.

Se si desidera la directory principale del processo in esecuzione, probabilmente si desidera utilizzare process.cwd().

Se si desidera la prevedibilità e l'affidabilità, è probabile che sia necessario impostare una determinata variabile di ambiente come requisito dell'applicazione. La tua app cerca MY_APP_HOME(o qualsiasi altra cosa) e se è lì, e l'applicazione esiste in quella directory, allora va tutto bene. Se non è definito o la directory non contiene l'applicazione, dovrebbe uscire con un errore che richiede all'utente di creare la variabile. Potrebbe essere impostato come parte di un processo di installazione.

Puoi leggere le variabili di ambiente nel nodo con qualcosa di simile process.env.MY_ENV_VARIABLE.

1- creare un file nella radice del progetto chiamarlo settings.js

2- all'interno di questo file aggiungi questo codice

module.exports = {
    POST_MAX_SIZE : 40 , //MB
    UPLOAD_MAX_FILE_SIZE: 40, //MB
    PROJECT_DIR : __dirname
};

3- all'interno di node_modules crea un nuovo modulo chiamandolo "settings" e all'interno del modulo index.js scrivi questo codice:

module.exports = require("../../settings");

4- e ogni volta che vuoi la tua directory di progetto basta usare

var settings = require("settings");
settings.PROJECT_DIR; 

in questo modo avrai tutte le directory di progetto relative a questo file;)

il modo più semplice per ottenere il root globale ( supponendo che tu usi NPM per eseguire l'app 'npm start' dell'app node.js, ecc. )

var appRoot = process.env.PWD;

Se si desidera verificare trasversalmente quanto sopra

Supponi di voler eseguire un controllo incrociato process.env.PWDcon le impostazioni della tua applicazione node.js. se si desidera che alcuni test di runtime ne verifichino la validità process.env.PWD, è possibile effettuare un controllo incrociato con questo codice (che ho scritto e che sembra funzionare bene). Puoi eseguire un controllo incrociato del nome dell'ultima cartella in appRoot con npm_package_name nel file package.json, ad esempio:

    var path = require('path');

    var globalRoot = __dirname; //(you may have to do some substring processing if the first script you run is not in the project root, since __dirname refers to the directory that the file is in for which __dirname is called in.)

    //compare the last directory in the globalRoot path to the name of the project in your package.json file
    var folders = globalRoot.split(path.sep);
    var packageName = folders[folders.length-1];
    var pwd = process.env.PWD;
    var npmPackageName = process.env.npm_package_name;
    if(packageName !== npmPackageName){
        throw new Error('Failed check for runtime string equality between globalRoot-bottommost directory and npm_package_name.');
    }
    if(globalRoot !== pwd){
        throw new Error('Failed check for runtime string equality between globalRoot and process.env.PWD.');
    }

puoi anche usare questo modulo NPM: require('app-root-path')che funziona molto bene per questo scopo

Ho trovato che funziona in modo coerente per me, anche quando l'applicazione viene invocata da una sottocartella, come può essere con alcuni framework di test, come Mocha:

process.mainModule.paths[0].split('node_modules')[0].slice(0, -1);

Perché funziona:

Al nodo di runtime crea un registro di tutti i percorsi di tutti i file caricati. I moduli vengono caricati per primi, quindi nella parte superiore di questo registro. Selezionando il primo elemento del registro e restituendo il percorso prima della directory 'node_modules' siamo in grado di determinare la radice dell'applicazione.

È solo una riga di codice, ma per semplicità (per amor mio), l'ho racchiusa in un modulo NPM:

https://www.npmjs.com/package/node-root.pddivine

Godere!

Tutte queste "directory principali" devono principalmente risolvere un percorso virtuale in un vero e proprio percorso a pila, quindi potresti essere tu a guardare path.resolve?

var path= require('path');
var filePath = path.resolve('our/virtual/path.ext');

Semplice come aggiungere questa linea al tuo modulo in root, di solito è app.js

global.__basedir = __dirname;

Quindi _basedir sarà accessibile a tutti i tuoi moduli.

Forse puoi provare a spostarti verso l'alto __filenamefino a quando non trovi un package.json, e decidere che è la directory principale a cui appartiene il tuo file corrente.

In realtà, trovo la soluzione forse banale anche per la più robusta: è sufficiente posizionare il seguente file nella directory principale del progetto: root-path.js che ha il seguente codice:

import * as path from 'path'
const projectRootPath = path.resolve(__dirname)
export const rootPath = projectRootPath

Una tecnica che ho trovato utile quando si utilizza express è quella di aggiungere quanto segue ad app.js prima che venga impostato uno qualsiasi degli altri percorsi

// set rootPath
app.use(function(req, res, next) {
  req.rootPath = __dirname;
  next();
});

app.use('/myroute', myRoute);

Non è necessario utilizzare i globali e il percorso della directory principale è una proprietà dell'oggetto richiesta.

Funziona se il tuo app.js è nella radice del tuo progetto che, per impostazione predefinita, lo è.

Aggiungilo da qualche parte all'inizio del file dell'app principale (ad esempio app.js):

global.__basedir = __dirname;

Questo imposta una variabile globale che sarà sempre equivalente alla directory base della tua app. Usalo come qualsiasi altra variabile:

const yourModule = require(__basedir + '/path/to/module.js');

Semplice...

So che questo è già troppo tardi. Ma possiamo recuperare l'URL di root con due metodi

1o metodo

var path = require('path');
path.dirname(require.main.filename);

2o metodo

var path = require('path');
path.dirname(process.mainModule.filename);

Link di riferimento: - https://gist.github.com/geekiam/e2e3e0325abd9023d3a3

C'è una INIT_CWDproprietà su process.env. Questo è ciò con cui sto attualmente lavorando nel mio progetto.

const {INIT_CWD} = process.env; // process.env.INIT_CWD 
const paths = require(`${INIT_CWD}/config/paths`);

In bocca al lupo...

se vuoi determinare la radice del progetto da un'applicazione node.js in esecuzione, puoi semplicemente farlo.

process.mainModule.path

Nella parte superiore del file principale aggiungi:

mainDir = __dirname;

Quindi utilizzalo in qualsiasi file di cui hai bisogno:

console.log('mainDir ' + mainDir);

• mainDirè definito a livello globale, se è necessario solo nel file corrente, utilizzare __dirnameinvece.
• file principale è di solito nella cartella principale del progetto ed è denominato come main.js, index.js, gulpfile.js.

Io lo uso

Per il mio modulo chiamato mymodule

var BASE_DIR = __dirname.replace(/^(.*\/mymodule)(.*)$/, '$1')

Renderlo sexy 💃🏻.

const users = require('../../../database/users'); // 👎 what you have
// OR
const users = require('$db/users'); // 👍 no matter how deep you are
const products = require('/database/products'); // 👍 alias or pathing from root directory

Tre semplici passaggi per risolvere il problema del brutto percorso.

1. Installa il pacchetto: npm install sexy-require --save
   

2. Includi require('sexy-require')una volta nella parte superiore del file dell'applicazione principale.

   require('sexy-require');
   const routers = require('/routers');
   const api = require('$api');
   ...

3. Passaggio opzionale. La configurazione del percorso può essere definita in un .pathsfile nella directory principale del progetto.

   $db = /server/database
   $api-v1 = /server/api/legacy
   $api-v2 = /server/api/v2

Questo farà scendere l'albero delle directory fino a quando non contiene una node_modulesdirectory, che di solito indica la radice del progetto:

const fs = require('fs')
const path = require('path')

function getProjectRoot(currentDir = __dirname.split(path.sep)) {
  if (!currentDir.length) {
    throw Error('Could not find project root.')
  }
  const nodeModulesPath = currentDir.concat(['node_modules']).join(path.sep)
  if (fs.existsSync(nodeModulesPath) && !currentDir.includes('node_modules')) {
    return currentDir.join(path.sep)
  }
  return this.getProjectRoot(currentDir.slice(0, -1))
}

Si assicura inoltre che non ci sia node_modulesnel percorso restituito, poiché ciò significa che è contenuto in un'installazione di pacchetto nidificata.

process.mainModuleè obsoleto dalla v 14.0.0. Quando si fa riferimento alla risposta, si prega di utilizzare require.main , il resto vale ancora.

process.mainModule.paths
  .filter(p => !p.includes('node_modules'))
  .shift()

Ottieni tutti i percorsi nei moduli principali e filtra quelli con "node_modules", quindi ottieni il primo dell'elenco dei percorsi rimanenti. Un comportamento imprevisto non genererà errori, ma solo unundefined .

Funziona bene per me, anche quando si chiama ie $ mocha.

Crea una funzione in app.js

/*Function to get the app root folder*/

var appRootFolder = function(dir,level){
    var arr = dir.split('\\');
    arr.splice(arr.length - level,level);
    var rootFolder = arr.join('\\');
    return rootFolder;
}

// view engine setup
app.set('views', path.join(appRootFolder(__dirname,1),'views'));

Puoi semplicemente aggiungere il percorso della directory principale nella variabile dell'app express e ottenere questo percorso dall'app. Per questo aggiungi il app.set('rootDirectory', __dirname);tuo file index.js o app.js. E utilizzare req.app.get('rootDirectory')per ottenere il percorso della directory principale nel codice.

Vecchia domanda, lo so, tuttavia nessuna domanda menzione da usare progress.argv. L'array argv include un percorso completo e un nome file (con o senza estensione .js) che è stato usato come parametro per essere eseguito dal nodo. Poiché anche questo può contenere flag, è necessario filtrarlo.

Questo non è un esempio che puoi usare direttamente (grazie all'utilizzo del mio framework) ma penso che ti dia un'idea di come farlo. Uso anche un metodo cache per evitare che chiamare questa funzione stressi troppo il sistema, specialmente quando non viene specificata alcuna estensione (ed è richiesto un controllo di file), ad esempio:

node myfile

o

node myfile.js

Questo è il motivo per cui lo memorizzo nella cache, vedi anche il codice qui sotto.

function getRootFilePath()
{
        if( !isDefined( oData.SU_ROOT_FILE_PATH ) )
        {
            var sExt = false;

            each( process.argv, function( i, v )
            {
                 // Skip invalid and provided command line options
                if( !!v && isValidString( v ) && v[0] !== '-' )
                {
                    sExt = getFileExt( v );

                    if( ( sExt === 'js' ) || ( sExt === '' && fileExists( v+'.js' )) )
                    {

                        var a = uniformPath( v ).split("/"); 

                         // Chop off last string, filename
                        a[a.length-1]='';

                         // Cache it so we don't have to do it again.
                        oData.SU_ROOT_FILE_PATH=a.join("/"); 

                         // Found, skip loop
                        return true;
                    }
                }
            }, true ); // <-- true is: each in reverse order
        }

        return oData.SU_ROOT_FILE_PATH || '';
    }
}; 

Trovare il percorso di root di un'app elettronica potrebbe essere complicato. Perché il percorso di root è diverso per il processo principale e il renderer in diverse condizioni come produzione, sviluppo e condizioni di pacchetto.

Ho scritto un pacchetto npm electron-root-path per catturare il percorso root di un'app elettronica.

$ npm install electron-root-path

or 

$ yarn add electron-root-path


// Import ES6 way
import { rootPath } from 'electron-root-path';

// Import ES2015 way
const rootPath = require('electron-root-path').rootPath;

// e.g:
// read a file in the root
const location = path.join(rootPath, 'package.json');
const pkgInfo = fs.readFileSync(location, { encoding: 'utf8' });

Questo farà:

path.join(...process.argv[1].split(/\/|\\/).slice(0, -1))

Funziona per me

process.env.PWD

Preambolo

Questa è una domanda molto vecchia ma sembra colpire ancora il nervo nel 2020 come nel 2012. Ho controllato tutte le altre risposte e non sono riuscito a trovare una tecnica (nota che questo ha i suoi limiti, ma tutti gli altri non lo sono applicabile anche in ogni situazione).

GIT + processo figlio

Se stai usando GIT come sistema di controllo della versione, il problema di determinare la radice del progetto può essere ridotto a (che considererei la radice corretta del progetto - dopo tutto, vorresti che il tuo VCS avesse il massimo campo di visibilità possibile) :

recuperare il percorso principale del repository

Poiché è necessario eseguire un comando CLI per farlo, sarà necessario generare un processo figlio. Inoltre, poiché è improbabile che root di progetto cambi a metà del runtime, child_processall'avvio possiamo usare la versione sincrona delle API del modulo.

Ho scoperto spawnSync()di essere il più adatto per il lavoro. Per quanto riguarda l'esecuzione effettiva del comando, git worktree(con --porcelainun'opzione per facilitare l'analisi) è tutto ciò di cui abbiamo bisogno per recuperare il percorso di root assoluto.

Nell'esempio ho scelto di restituire una matrice di percorsi perché potrebbe esserci più di un worktree (anche se è probabile che abbiano percorsi comuni) solo per essere sicuri. Si noti che quando utilizziamo un comando CLI, l' shellopzione dovrebbe essere impostata su true(la sicurezza non dovrebbe essere un problema in quanto non vi sono input non attendibili).

Confronto di approccio e fallback

Comprendendo che una situazione in cui VCS può essere inaccessibile, ho incluso un paio di fallback dopo aver analizzato documenti e altre risposte. Per riassumere, le soluzioni proposte si riducono a (esclusi i moduli di terze parti e specifici del pacchetto):

| Soluzione | Vantaggio | Problema principale |
| ------------------------ | ----------------------- | -------------------------------- |
| `__filename` | punta al file del modulo | rispetto al modulo |
| `__dirname` | punta al modulo dir | uguale a `__filename` |
| passeggiata sull'albero `node_modules` | radice quasi garantita | albero complesso che cammina se nidificato |
| `path.resolve (". ")` | root se CWD è root | uguale a `process.cwd ()` |
| `process.argv [1]` | uguale a `__filename` | uguale a `__filename` |
| `process.env.INIT_CWD` | punta a `npm run` dir | richiede il lancio di `npm` && CLI |
| `process.env.PWD` | punta alla directory corrente | relativamente a (è il) dir di avvio |
| `process.cwd ()` | uguale a `env.PWD` | `process.chdir (percorso)` in fase di esecuzione |
| `require.main.filename` | root se `=== module` | non riesce sui moduli `request`d |

Dalla tabella di confronto sopra, i più universali sono due approcci:

• require.main.filenamecome un modo semplice per ottenere root se require.main === moduleè soddisfatto
• node_modulesla passeggiata sugli alberi proposta di recente usa un'altra ipotesi:

se la directory del modulo ha node_modulesdir all'interno, è probabile che sia la root

Per l'app principale otterrà l'app root e per il modulo - la radice del progetto.

Fallback 1. Camminata sugli alberi

La mia implementazione usa un approccio più rilassato fermandosi quando viene trovata una directory di destinazione poiché per un dato modulo la sua radice è la radice del progetto. È possibile concatenare le chiamate o estenderle per rendere configurabile la profondità di ricerca:

/**
 * @summary gets root by walking up node_modules
 * @param {import("fs")} fs
 * @param {import("path")} pt
 */
const getRootFromNodeModules = (fs, pt) =>

    /**
     * @param {string} [startPath]
     * @returns {string[]}
     */
    (startPath = __dirname) => {

        //avoid loop if reached root path
        if (startPath === pt.parse(startPath).root) {
            return [startPath];
        }

        const isRoot = fs.existsSync(pt.join(startPath, "node_modules"));

        if (isRoot) {
            return [startPath];
        }

        return getRootFromNodeModules(fs, pt)(pt.dirname(startPath));
    };

Fallback 2. Modulo principale

La seconda implementazione è banale

/**
 * @summary gets app entry point if run directly
 * @param {import("path")} pt
 */
const getAppEntryPoint = (pt) =>

    /**
     * @returns {string[]}
     */
    () => {

        const { main } = require;

        const { filename } = main;

        return main === module ?
            [pt.parse(filename).dir] :
            [];
    };

Implementazione

Suggerirei di utilizzare il walker come fallback perché è più versatile:

const { spawnSync } = require("child_process");
const pt = require('path');
const fs = require("fs");

/**
 * @summary returns worktree root path(s)
 * @param {function : string[] } [fallback]
 * @returns {string[]}
 */
const getProjectRoot = (fallback) => {

    const { error, stdout } = spawnSync(
        `git worktree list --porcelain`,
        {
            encoding: "utf8",
            shell: true
        }
    );

    if (!stdout) {
        console.warn(`Could not use GIT to find root:\n\n${error}`);
        return fallback ? fallback() : [];
    }

    return stdout
        .split("\n")
        .map(line => {
            const [key, value] = line.split(/\s+/) || [];
            return key === "worktree" ? value : "";
        })
        .filter(Boolean);
};

svantaggi

Il più ovvio è avere GIT installato e inizializzato che potrebbe essere indesiderabile / non plausibile (nota a margine: avere GIT installato su server di produzione non è raro, ma non è sicuro ). Può essere mediato da fallback come descritto sopra.

Appunti

1. Un paio di idee per un'ulteriore estensione dell'approccio 1:
   • introdurre config come parametro di funzione
   • export la funzione per renderlo un modulo
   • controlla se GIT è installato e / o inizializzato

Riferimenti

1. git worktree riferimento
2. spawnSync riferimento
3. require.main riferimento
4. path.dirname() riferimento

Semplice: require('path').resolve('./')

Provare path._makeLong('some_filename_on_root.js');

esempio:

cons path = require('path');
console.log(path._makeLong('some_filename_on_root.js');

Ciò restituirà il percorso completo dalla radice dell'applicazione del nodo (stessa posizione di package.json)

Usa solo:

 path.resolve("./") ... output is your project root directory

path.dirname(process.mainModule.filename);