Determinar a raiz do projeto a partir de um aplicativo node.js em execução


315

Existe uma maneira melhor do process.cwd()que determinar o diretório raiz de um processo node.js em execução? Algo como o equivalente a Rails.root, mas para Node.js. Estou procurando por algo o mais previsível e confiável possível.


1
Alguma chance de você não aceitar a resposta aceita e errada?
Dave Newton

9
tente process.env.PWD... veja minha resposta abaixo.
Alexander Mills

Respostas:


624

Existem várias maneiras de abordar isso, cada uma com seus próprios prós e contras:

require.main.filename

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

Quando um arquivo é executado diretamente do Node, require.mainé definido como module. Isso significa que você pode determinar se um arquivo foi executado diretamente testandorequire.main === module

Como modulefornece uma filenamepropriedade (normalmente equivalente a __filename), o ponto de entrada do aplicativo atual pode ser obtido verificando require.main.filename.

Portanto, se você deseja o diretório base para seu aplicativo, pode:

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

Prós e contras

Isso funcionará muito bem na maioria das vezes, mas se você estiver executando seu aplicativo com um iniciador como pm2 ou executando testes mocha , esse método falhará.

global.X

O nó possui um objeto de espaço para nome global chamado global- tudo o que você anexa a esse objeto estará disponível em qualquer lugar do seu aplicativo. Portanto, no seu index.js(ou no app.jsnome do arquivo principal do aplicativo), você pode definir apenas uma variável global:

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

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

Prós e contras

Funciona de forma consistente, mas você precisa confiar em uma variável global, o que significa que você não pode reutilizar facilmente componentes / etc.

process.cwd ()

Isso retorna o diretório de trabalho atual. Não confiável em tudo, como é inteiramente dependente do que diretório o processo foi lançado a partir de :

$ 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

caminho da raiz do aplicativo

Para solucionar esse problema, criei um módulo de nó chamado app-root-path . O uso é simples:

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

O módulo app-root-path usa várias técnicas diferentes para determinar o caminho raiz do aplicativo, levando em consideração os módulos instalados globalmente (por exemplo, se o aplicativo estiver em execução, /var/www/mas o módulo estiver instalado ~/.nvm/v0.x.x/lib/node/). Não funcionará 100% do tempo, mas funcionará nos cenários mais comuns.

Prós e contras

Funciona sem configuração na maioria das circunstâncias. Também fornece alguns bons métodos de conveniência adicionais (consulte a página do projeto). O maior engodo é que não funcionará se:

  • Você está usando um iniciador, como pm2
  • E , o módulo não está instalado no node_modulesdiretório do seu aplicativo (por exemplo, se você o instalou globalmente)

Você pode contornar isso definindo uma APP_ROOT_PATHvariável ambiental ou chamando .setPath()o módulo, mas, nesse caso, provavelmente é melhor usar o globalmétodo

Variável de ambiente NODE_PATH

Se você está procurando uma maneira de determinar o caminho raiz do aplicativo atual, é provável que uma das soluções acima funcione melhor para você. Se, por outro lado, você estiver tentando resolver o problema de carregar módulos de aplicativos de forma confiável, eu recomendo analisar a NODE_PATHvariável ambiental.

O sistema Node's Modules procura módulos em vários locais. Um desses locais é onde process.env.NODE_PATHpontos . Se você definir essa variável de ambiente, poderá efetuar requiremódulos com o carregador de módulos padrão sem outras alterações.

Por exemplo, se você definir NODE_PATHcomo /var/www/lib, o seguinte funcionaria perfeitamente:

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

Uma ótima maneira de fazer isso é usando npm:

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

Agora você pode iniciar o seu aplicativo npm starte você está dourado. Combino isso com meu módulo enforce-node-path , que impede o carregamento acidental do aplicativo sem NODE_PATHdefinir. Para obter ainda mais controle sobre a aplicação de variáveis ​​ambientais, consulte checkenv .

Uma pegadinha: NODE_PATH deve ser configurada fora do aplicativo do nó. Você não pode fazer algo assim process.env.NODE_PATH = path.resolve(__dirname)porque o carregador de módulos armazena em cache a lista de diretórios que ele pesquisará antes de o aplicativo ser executado.

[adicionado em 4/6/16] Outro módulo realmente promissor que tenta resolver esse problema é ondulado .


1
@ Kevin, nesse caso, o mocha é o ponto de entrada do seu aplicativo. Este é apenas um exemplo de por que encontrar a "raiz do projeto" é tão difícil - depende muito da situação e do que você quer dizer com "raiz do projeto".
Inxilpro

1
@ Kevin eu entendo completamente. O que quero dizer é que o conceito de "raiz do projeto" é muito mais fácil para um ser humano do que um computador . Se você deseja um método infalível, precisa configurá-lo. Usando require.main.filenamevai trabalhar mais do tempo, mas não todo o tempo.
Inxilpro

2
Tangencialmente relacionados: esta é uma forma incrivelmente inteligente para organizar seu projeto Nó de modo que você não precisa se preocupar com este problema tanto: allanhortle.com/2015/02/04/...
inxilpro

1
Não sei se houve uma alteração no pm2 ou no Node.js, mas require.main.filenameparece funcionar com o pm2. Não sei sobre mocha.
Justin Warkentin

8
path.parse(process.mainModule.filename).dir
Cory Robinson

53

__dirnamenão é global; é local para o módulo atual, então cada arquivo tem seu próprio valor local e diferente.

Se você deseja o diretório raiz do processo em execução, provavelmente deseja usá-lo process.cwd().

Se você deseja previsibilidade e confiabilidade, provavelmente precisará exigir que seu aplicativo defina uma determinada variável de ambiente. Seu aplicativo procura MY_APP_HOME(ou o que for) e, se estiver lá, e o aplicativo existe nesse diretório, tudo está bem. Se não estiver definido ou o diretório não contiver seu aplicativo, ele deverá sair com um erro solicitando ao usuário que crie a variável. Pode ser definido como parte de um processo de instalação.

Você pode ler variáveis ​​de ambiente no nó com algo parecido process.env.MY_ENV_VARIABLE.


2
Se usado com cautela, isso pode funcionar muito bem. Mas daria resultados diferentes quando fazendo bin/server.jsvs cd bin && server.js. (assumindo que estas js arquivos são marcados sendo executável)
Myrne Stol

1
Usar process.cwd()funcionou como um encanto para mim, mesmo ao executar testes mocha. Obrigado!
Diogo Eichert 23/03/19

49

1- crie um arquivo na raiz do projeto, chame-o settings.js

2- dentro deste arquivo, adicione este código

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

3- dentro de node_modules, crie um novo módulo denomine "settings" e dentro do módulo index.js escreva este código:

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

4- e sempre que quiser o diretório do projeto, use

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

dessa forma, você terá todos os diretórios do projeto em relação a esse arquivo;)


33
-1: Para carregar o arquivo de configurações, você precisa de um caminho, para obter o caminho de referência para esse arquivo? Não resolvendo nada ...
goliatone

2
Voto a favor de reservar um tempo para revisar e editar. Ele ainda se sente frágil, mas isso pode ser apenas porque não há uma maneira melhor de conseguir isso
goliatone

8
Algo que os usuários desejam ter em mente com essa abordagem é que node_modulesgeralmente é excluído do controle de versão. Portanto, se você trabalha com uma equipe ou precisa clonar seu repositório, precisará criar outra solução para manter esse arquivo de configurações sincronizado.
precisa

@ Travesty3 no módulo de configuração é realmente um módulo vazio que está a exportar o conteúdo de um arquivo na raiz do projeto: P
Fareed Alnamrouti

@goliatone Com sua solução, você pode obter o arquivo de qualquer lugar sem conhecer seu caminho, tudo o que você precisa saber é "configurações". Sem ele, você precisaria saber explicitamente quantas pastas serão recuperadas até chegar ao diretório do projeto. Isso funciona porque o nó pesquisa automaticamente node_modules e sempre sabe onde está.

26

a maneira mais fácil de obter a raiz global ( supondo que você use o NPM para executar o aplicativo node.js 'npm start', etc )

var appRoot = process.env.PWD;

Se você deseja verificar cruzadamente o acima

Digamos que você queira verificar process.env.PWDcom as configurações do seu aplicativo node.js. se você quiser que alguns testes de tempo de execução verifiquem a validade process.env.PWD, verifique com este código (que escrevi o que parece funcionar bem). Você pode verificar o nome da última pasta no appRoot com o npm_package_name no arquivo package.json, por exemplo:

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

você também pode usar este módulo NPM: require('app-root-path')que funciona muito bem para essa finalidade


5
Isso funciona muito bem na (maioria) dos sistemas unix. Assim que você desejar que seu módulo / aplicativo npm funcione no Windows, ele PWDserá indefinido e isso falhará.
21417 Jeremy Wiebe #

1
process.cwd()
Muhammad Umer

@MuhammadUmer por que process.cwd()sempre seria o mesmo que a raiz do projeto?
Alexander Mills

se você chamá-lo no arquivo raiz, então seria
Muhammad Umer 5/05

14

Descobri que isso funciona consistentemente para mim, mesmo quando o aplicativo é chamado de uma subpasta, como pode ser em algumas estruturas de teste, como o Mocha:

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

Por que funciona:

No tempo de execução, o nó cria um registro dos caminhos completos de todos os arquivos carregados. Os módulos são carregados primeiro e, portanto, na parte superior deste registro. Selecionando o primeiro elemento do registro e retornando o caminho antes do diretório 'node_modules', podemos determinar a raiz do aplicativo.

É apenas uma linha de código, mas por uma questão de simplicidade (por minha causa), coloquei-o na caixa preta em um módulo NPM:

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

Aproveitar!


1
process.mainModule preterido desde: v14.0.0 - use em seu require.main.paths[0].split('node_modules')[0].slice(0, -1);lugar.
RobC

10

Todos esses "diretórios raiz" precisam principalmente resolver algum caminho virtual para um caminho de pilha real, então você deve procurar path.resolve?

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

9

Tão simples quanto adicionar esta linha ao seu módulo na raiz, geralmente é app.js

global.__basedir = __dirname;

Então _basedir estará acessível a todos os seus módulos.


8

Talvez você possa tentar avançar __filenameaté encontrar um package.jsone decidir que é o diretório principal ao qual seu arquivo atual pertence.


7

Na verdade, acho a solução talvez trivial também a mais robusta: você simplesmente coloca o seguinte arquivo no diretório raiz do seu projeto: root-path.js, que possui o seguinte código:

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

4

Uma técnica que eu achei útil ao usar o express é adicionar o seguinte ao app.js antes que qualquer outra rota seja definida

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

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

Não há necessidade de usar globais e você tem o caminho do diretório raiz como uma propriedade do objeto de solicitação.

Isso funciona se o seu app.js estiver na raiz do seu projeto e, por padrão, ele estiver.


4

Adicione isso em algum lugar no início do seu arquivo principal do aplicativo (por exemplo, app.js):

global.__basedir = __dirname;

Isso define uma variável global que sempre será equivalente ao diretório base do seu aplicativo. Use-o como qualquer outra variável:

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

Simples...


3

Eu sei que este já é tarde demais. Mas podemos buscar o URL raiz por dois métodos

1º método

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

Segundo método

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

Link de referência: - https://gist.github.com/geekiam/e2e3e0325abd9023d3a3


3

Existe uma INIT_CWDpropriedade em process.env. É com isso que estou trabalhando atualmente no meu projeto.

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

Boa sorte...


1
Funcionou como um encanto para um pacote que manipula o projeto do qual está sendo chamado como uma etapa de pós-instalação. No entanto, ainda não o testei em outra camada de dependência, onde um projeto usa uma dependência que usa meu pacote.
21419 JamesDev

1
@JamesDev, INIT_CWDresolve para o directoryqual npm-scriptfoi efetuado.
Akash

2

se você deseja determinar a raiz do projeto a partir de um aplicativo node.js.js, você também pode simplesmente.

process.mainModule.path

1

No topo do arquivo principal, adicione:

mainDir = __dirname;

Em seguida, use-o em qualquer arquivo necessário:

console.log('mainDir ' + mainDir);
  • mainDiré definido globalmente, se você precisar apenas no arquivo atual - use __dirname.
  • arquivo principal é geralmente na pasta raiz do projeto e é nomeado como main.js, index.js, gulpfile.js.

1

Eu uso isso.

Para o meu módulo chamado mymodule

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


1

Torná-lo 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


Três etapas simples para resolver o problema do caminho feio.

  1. Instale o pacote: npm install sexy-require --save
  2. Inclua require('sexy-require')uma vez na parte superior do arquivo principal do aplicativo.

    require('sexy-require');
    const routers = require('/routers');
    const api = require('$api');
    ...
  3. Etapa opcional. A configuração do caminho pode ser definida no .pathsarquivo no diretório raiz do seu projeto.

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

Parece decente, pena que tinha um nome tão ridículo.
JHH

@JHH bem ... Eu tinha que encontrar um nome melhor
sultão

1

Isso reduzirá a árvore de diretórios até que ele contenha um node_modulesdiretório, o que geralmente indica a raiz do seu projeto:

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))
}

Ele também garante que não haja nenhum node_modulesno caminho retornado, pois isso significa que ele está contido em uma instalação de pacote aninhada.


1

process.mainModulefoi descontinuado desde a v 14.0.0. Ao se referir à resposta, por favor , use require.main , o resto ainda é válido.

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

Obtenha todos os caminhos nos módulos principais e filtre aqueles com "node_modules" e, em seguida, obtenha o primeiro da lista de caminhos restante. Comportamento inesperado não gera erro, apenas um undefined.

Funciona bem para mim, mesmo quando chamando ie $ mocha.


0

Crie uma função no 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'));

0

Você pode simplesmente adicionar o caminho do diretório raiz na variável de aplicativo expresso e obter esse caminho no aplicativo. Para isso, adicione app.set('rootDirectory', __dirname);seu arquivo index.js ou app.js. E use req.app.get('rootDirectory')para obter o caminho do diretório raiz no seu código.


0

Questão antiga, eu sei, porém nenhuma pergunta é mencionada progress.argv. A matriz argv inclui um nome de caminho e nome de arquivo completos (com ou sem extensão .js) que foram usados ​​como parâmetro a ser executado pelo nó. Como isso também pode conter sinalizadores, você deve filtrar isso.

Este não é um exemplo que você pode usar diretamente (devido ao uso de minha própria estrutura), mas acho que dá uma idéia de como fazê-lo. Também uso um método de cache para evitar que a chamada dessa função exija muito do sistema, especialmente quando nenhuma extensão é especificada (e é necessária uma verificação de arquivo), por exemplo:

node myfile

ou

node myfile.js

Essa é a razão pela qual eu o cache, veja também o código abaixo.


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 || '';
    }
}; 

0

Encontrar o caminho raiz de um aplicativo de elétrons pode ser complicado. Como o caminho raiz é diferente para o processo principal e o renderizador em diferentes condições, como condições de produção, desenvolvimento e empacotamento.

Eu escrevi um pacote npm electron-root-path para capturar o caminho raiz de um aplicativo de elétrons.

$ 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' });

0

Isso fará:

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


0

Preâmbulo

Essa é uma pergunta muito antiga, mas parece que ainda está atrapalhando em 2020, como em 2012. Verifiquei todas as outras respostas e não consegui encontrar uma técnica (observe que isso tem suas limitações, mas todas as outras não são). aplicável em todas as situações).

Processo filho GIT +

Se você estiver usando o GIT como seu sistema de controle de versão, o problema de determinar a raiz do projeto pode ser reduzido para (o que eu consideraria a raiz apropriada do projeto - afinal, você gostaria que o seu VCS tivesse o maior escopo de visibilidade possível) :

recuperar o caminho raiz do repositório

Como você precisa executar um comando da CLI para fazer isso, precisamos gerar um processo filho. Além disso, como é improvável que a raiz do projeto mude no meio do tempo de execução, podemos usar a versão síncrona das child_processAPIs do módulo na inicialização.

Eu achei spawnSync()o mais adequado para o trabalho. Quanto ao comando real a ser executado git worktree(com uma --porcelainopção para facilitar a análise) é tudo o que precisamos para recuperar o caminho raiz absoluto.

Na amostra, optei por retornar uma matriz de caminhos porque pode haver mais de uma árvore de trabalho (embora eles provavelmente tenham caminhos comuns) apenas para ter certeza. Observe que, à medida que utilizamos um comando da CLI, a shellopção deve ser definida como true(a segurança não deve ser um problema, pois não há entrada não confiável).

Comparação de abordagem e fallbacks

Entendendo que uma situação em que o VCS pode ser inacessível, incluí algumas alternativas depois de analisar documentos e outras respostas. Em resumo, as soluções propostas se resumem a (excluindo módulos de terceiros e específicos de pacotes):

| Solução | Vantagem | Problema principal |
| ------------------------ | ----------------------- | -------------------------------- |
| `__filename` | aponta para o arquivo do módulo | em relação ao módulo |
| `__dirname` | aponta para o módulo dir | o mesmo que `__filename` |
| caminhada na árvore do `node_modules` | raiz quase garantida | árvore complexa andando se aninhada |
| `path.resolve (". ")` | raiz se CWD for raiz | o mesmo que `process.cwd ()` |
| `process.argv [1]` | mesmo que `__filename` | o mesmo que `__filename` |
| `process.env.INIT_CWD` | aponta para `npm run` dir | requer `npm` e & lançamento do CLI |
| `process.env.PWD` | aponta para dir atual | relativo a (é o) dir de lançamento |
| `process.cwd ()` | o mesmo que `env.PWD` | `process.chdir (path)` em tempo de execução |
| `require.main.filename` | raiz se `=== módulo` | falha nos módulos `require`d |

Na tabela de comparação acima, as mais universais são duas abordagens:

  • require.main.filenamecomo uma maneira fácil de obter root se require.main === modulefor atendida
  • node_modulesO passeio em árvore proposto recentemente usa outra suposição:

se o diretório do módulo tiver node_modulesdir dentro, é provável que seja a raiz

Para o aplicativo principal, ele obtém a raiz do aplicativo e o módulo - a raiz do projeto.

Fallback 1. Caminhada na árvore

Minha implementação usa uma abordagem mais relaxada, parando quando um diretório de destino é encontrado, pois para um determinado módulo sua raiz é a raiz do projeto. Pode-se encadear as chamadas ou ampliá-las para tornar a profundidade da pesquisa configurável:

/**
 * @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. Módulo principal

A segunda implementação é trivial

/**
 * @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] :
            [];
    };

Implementação

Eu sugiro usar o walker de árvore como substituto, porque é mais versátil:

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

Desvantagens

O mais óbvio é ter o GIT instalado e inicializado, o que pode ser indesejável / implausível (observação: ter o GIT instalado nos servidores de produção não é incomum , embora não seja seguro ). Pode ser mediado por fallbacks, conforme descrito acima.

Notas

  1. Algumas idéias para uma maior extensão da abordagem 1:
    • introduzir configuração como parâmetro de função
    • export a função de torná-lo um módulo
    • verifique se o GIT está instalado e / ou inicializado

Referências

  1. git worktree referência
  2. spawnSync referência
  3. require.main referência
  4. path.dirname() referência


-1

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

exemplo:

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

Isso retornará o caminho completo da raiz do aplicativo do nó (mesma posição do package.json)


-1

Apenas use:

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

isso funciona muito bem! path.resolve (".") funciona também
Noel Schenk

Isso fornece apenas o diretório atual, que pode não ser o diretório raiz.
orad 15/08/19

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.