Определить корень проекта из работающего приложения node.js


315

Есть ли лучший способ, чем process.cwd()определить корневой каталог работающего процесса node.js? Что-то вроде эквивалента Rails.root, но для Node.js. Я ищу что-то настолько предсказуемое и надежное, насколько это возможно.


1
Есть ли шанс, что вы можете принять принятый, неправильный ответ?
Дэйв Ньютон,

9
попробуйте process.env.PWD... см. мой ответ ниже.
Александр Миллс

Ответы:


624

Есть несколько способов подойти к этому, каждый со своими плюсами и минусами:

require.main.filename

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

Когда файл запускается непосредственно из Node, require.mainустанавливается его module. Это означает, что вы можете определить, был ли файл запущен напрямую, путем тестированияrequire.main === module

Поскольку moduleпредоставляет filenameсвойство (обычно эквивалентное __filename), точка входа текущего приложения может быть получена путем проверки require.main.filename.

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

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

За и против

Это будет работать отлично большую часть времени, но если вы используете приложение с пусковым как PM2 или бегом мокко испытания, этот метод не получится .

global.X

Узел имеет глобальный объект пространства имен, который называется global- все, что вы прикрепите к этому объекту, будет доступно везде в вашем приложении. Таким образом, в вашем index.js(или app.jsкак называется ваш основной файл приложения), вы можете просто определить глобальную переменную:

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

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

За и против

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

process.cwd ()

Это возвращает текущий рабочий каталог. Не надежны вообще, так как это полностью зависит от того, что каталог процесс был запущен из :

$ 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 . Использование простое:

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

Модуль app-root-path использует несколько различных методов для определения корневого пути приложения с учетом глобально установленных модулей (например, если ваше приложение работает, /var/www/но модуль установлен ~/.nvm/v0.x.x/lib/node/). Это не будет работать 100% времени, но это будет работать в большинстве распространенных сценариев.

За и против

Работает без конфигурации в большинстве случаев. Также предоставляет несколько приятных дополнительных удобных методов (см. Страницу проекта). Самый большой недостаток в том, что он не будет работать, если:

  • Вы используете лаунчер, например, pm2
  • И , модуль не установлен внутри node_modulesкаталога вашего приложения (например, если вы установили его глобально)

Вы можете обойти это, установив APP_ROOT_PATHпеременную окружения или вызвав .setPath()модуль, но в этом случае вам, вероятно, лучше использовать globalметод.

NODE_PATH переменная среды

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

Система модулей Node ищет модули в разных местах. Одно из этих мест - везде, куда process.env.NODE_PATHуказывает . Если вы установите эту переменную среды, то вы можете requireмодули со стандартным загрузчиком модулей без каких-либо других изменений.

Например, если вы установите NODE_PATHна /var/www/lib, то следующее будет работать нормально:

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

Отличный способ сделать это с помощью npm:

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

Теперь вы можете начать свое приложение с npm startи вы золотой. Я объединяю это с моим модулем forcece-node-path , который предотвращает случайную загрузку приложения без NODE_PATHнабора. Для еще большего контроля над выполнением переменных среды см. Checkenv .

Одна ошибка: NODE_PATH должна быть установлена вне приложения узла. Вы не можете сделать что-то подобное, process.env.NODE_PATH = path.resolve(__dirname)потому что загрузчик модулей кэширует список каталогов, в которых он будет искать, прежде чем ваше приложение запустится.

[добавлено 6/6/16] Другой действительно многообещающий модуль, который пытается решить эту проблему, является волнистым .


1
@Kevin в этом случае, мокко является точкой входа вашего приложения. Это всего лишь пример того, почему найти «корень проекта» так сложно - это так сильно зависит от ситуации и того, что вы подразумеваете под «корнем проекта».
inxilpro

1
@ Кевин, я полностью понимаю. Я хочу сказать, что понятие «корень проекта» гораздо проще понять человеку, чем компьютеру . Если вы хотите надежный метод, вам нужно настроить его. Использование require.main.filenameбудет работать большую часть времени, но не всегда .
Inxilpro

2
Связанные с тангенциальной точки зрения: это невероятно умный способ организовать свой проект Node, чтобы вам не приходилось так сильно беспокоиться об этой проблеме: allanhortle.com/2015/02/04/…
inxilpro

1
Я не знаю, было ли изменение в pm2 или изменение с Node.js, но, require.main.filenameкажется, работает с pm2. Не знаю насчет мокко.
Джастин Варкентин

8
path.parse(process.mainModule.filename).dir
Кори Робинсон

53

__dirnameне глобальный; он является локальным по отношению к текущему модулю, поэтому каждый файл имеет свое собственное локальное значение.

Если вам нужен корневой каталог запущенного процесса, вы, вероятно, захотите его использовать process.cwd().

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

Вы можете читать переменные окружения в узле с чем-то вроде process.env.MY_ENV_VARIABLE.


2
Если использовать с осторожностью, это может работать довольно хорошо. Но это дало бы разные результаты при выполнении bin/server.jsпротив cd bin && server.js. (при условии, что эти js-файлы помечены как исполняемые)
Myrne Stol

1
Использование process.cwd()сработало для меня как прелесть, даже при проведении тестов мокко. Спасибо!
Диого Айхерт

49

1- создайте файл в корне проекта, назовите его settings.js

2- внутри этого файла добавьте этот код

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

3 - внутри node_modules создайте новый модуль, назовите его «settings», а внутри модуля index.js напишите этот код:

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

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

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

таким образом, у вас будут все каталоги проекта, относящиеся к этому файлу;)


33
-1: чтобы загрузить файл настроек, вам нужен путь, чтобы потом получить ссылку на этот файл? Ничего не решая ...
Голиатоне

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

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

@ Travesty3 модуль настроек - это фактически пустой модуль, который экспортирует содержимое файла в корень проекта: P
Fareed Alnamrouti

@goliatone С его решением вы можете получить файл из любого места, не зная его пути, все, что вам нужно знать, это «настройки». Без этого вам пришлось бы явно знать, сколько папок нужно удалить, пока не дойдете до каталога проекта. Это работает, потому что узел автоматически ищет node_modules и всегда знает, где это находится.

26

самый простой способ получить глобальный корень ( при условии, что вы используете NPM для запуска приложения node.js 'npm start' и т. д. )

var appRoot = process.env.PWD;

Если вы хотите перепроверить выше

Допустим, вы хотите перепроверить process.env.PWDнастройки вашего приложения node.js. если вы хотите, чтобы некоторые тесты во время выполнения проверяли достоверность process.env.PWD, вы можете перепроверить его с помощью этого кода (который я написал, который, кажется, работает хорошо). Вы можете перепроверить имя последней папки в appRoot с помощью npm_package_name в вашем файле package.json, например:

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

Вы также можете использовать этот модуль NPM: require('app-root-path')который очень хорошо работает для этой цели


5
Это прекрасно работает на (большинстве) Unix-системах. Как только вы захотите, чтобы ваш модуль / приложение npm работал в Windows, значение PWDне определено, и это не удается.
Джереми Вибе,

1
process.cwd()
Мухаммед Умер

@MuhammadUmer почему бы process.cwd()всегда быть таким же, как корень проекта?
Александр Миллс

если вы называете это в корневом файле, то это будет
Мухаммед Умер

14

Я обнаружил, что это работает последовательно для меня, даже когда приложение вызывается из подпапки, как это может быть с некоторыми тестовыми средами, такими как Mocha:

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

Почему это работает:

Во время выполнения узел создает реестр полных путей всех загруженных файлов. Модули загружаются в первую очередь, и, таким образом, в верхней части этого реестра. Выбрав первый элемент реестра и вернув путь перед каталогом «node_modules», мы можем определить корень приложения.

Это всего лишь одна строка кода, но для простоты (ради меня) я поместил ее в черный модуль NPM:

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

Наслаждайтесь!


1
process.mainModule deprectaed начиная с: v14.0.0 - используйте require.main.paths[0].split('node_modules')[0].slice(0, -1);вместо.
RobC

10

Все эти «корневые каталоги» в основном должны разрешать какой-то виртуальный путь к реальному пути кучи, так что, может быть, вам стоит посмотреть path.resolve?

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

9

Просто добавьте эту строку в свой модуль в корне, обычно это app.js

global.__basedir = __dirname;

Тогда _basedir будет доступен для всех ваших модулей.


8

Может быть, вы можете попробовать перейти вверх, __filenameпока не найдете package.json, и решить, что это основной каталог, к которому принадлежит ваш текущий файл.


7

На самом деле, я считаю, возможно, тривиальное решение для большинства надежных: вы просто помещаете следующий файл в корневой каталог вашего проекта: root-path.js, который имеет следующий код:

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

4

Техника, которую я нашел полезной при использовании Express, заключается в добавлении следующего в app.js перед настройкой любого из ваших других маршрутов.

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

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

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

Это работает, если ваш app.js находится в корне вашего проекта, что по умолчанию.


4

Добавьте это где-нибудь в начале вашего основного файла приложения (например, app.js):

global.__basedir = __dirname;

Это устанавливает глобальную переменную, которая всегда будет эквивалентна базовой директории вашего приложения. Используйте его как любую другую переменную:

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

Просто...


3

Я знаю, что это уже слишком поздно. Но мы можем получить корневой URL двумя способами

1-й метод

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

2-й метод

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

Ссылка Ссылка: - https://gist.github.com/geekiam/e2e3e0325abd9023d3a3


3

Есть INIT_CWDсобственность на process.env. Это то, с чем я сейчас работаю в своем проекте.

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

Удачи...


1
Работал как прелесть для пакета, который манипулирует проектом, из которого он вызывается как шаг после установки. Однако я еще не тестировал его на другом уровне зависимости, где проект использует зависимость, которая использует мой пакет.
JamesDev

1
@JamesDev, INIT_CWDразрешает до того, directoryиз которого npm-scriptбыл извлечен.
Акаш

2

если вы хотите определить корень проекта из работающего приложения node.js, вы можете просто тоже.

process.mainModule.path

1

Вверху основного файла добавьте:

mainDir = __dirname;

Затем используйте его в любом файле:

console.log('mainDir ' + mainDir);
  • mainDirопределяется глобально, если вам нужно только в текущем файле - используйте __dirnameвместо этого.
  • Основной файл, как правило , в корневой папке проекта и назван как main.js, index.js, gulpfile.js.

1

Я использую это.

Для моего модуля имени mymodule

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


1

Сделай это сексуально 💃🏻.

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


Три простых шага, чтобы решить проблему безобразного пути.

  1. Установите пакет: npm install sexy-require --save
  2. Включите require('sexy-require')один раз в верхней части вашего основного файла приложения.

    require('sexy-require');
    const routers = require('/routers');
    const api = require('$api');
    ...
  3. Необязательный шаг. Конфигурация пути может быть определена в .pathsфайле в корневом каталоге вашего проекта.

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

Кажется приличным, жаль, что у него было такое нелепое имя.
JHH

@JHH ну ... мне нужно было найти лучшее имя
султан

1

Это будет понижать дерево каталогов до тех пор, пока оно не будет содержать node_modulesкаталог, который обычно указывает на корневой каталог вашего проекта:

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

Это также гарантирует, что node_modulesв возвращаемом пути его нет, поскольку это означает, что он содержится в установке с вложенным пакетом.


1

process.mainModuleявляется устаревшим , так как против 14.0.0. При обращении к ответу, пожалуйста, используйте require.main , остальное все равно остается.

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

Получить все пути в основных модулях и отфильтровать их с помощью «node_modules», затем получить первый из оставшихся списков путей. Неожиданное поведение не приведет к ошибке, просто undefined.

Работает хорошо для меня, даже при вызове ИЭ $ mocha.


0

Создать функцию в 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

Вы можете просто добавить путь к корневому каталогу в переменной экспресс-приложения и получить этот путь из приложения. Для этого добавьте app.set('rootDirectory', __dirname);в свой файл index.js или app.js. И использовать req.app.get('rootDirectory')для получения пути к корневому каталогу в вашем коде.


0

Старый вопрос, я знаю, однако никаких вопросов упомянуть, чтобы использовать progress.argv. Массив argv включает в себя полный путь и имя файла (с расширением .js или без него), который использовался в качестве параметра для выполнения узлом. Поскольку это также может содержать флаги, вы должны фильтровать это.

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

node myfile

или

node myfile.js

Вот почему я кеширую это, см. Также код ниже.


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

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

Я написал пакет электронного пути-корня пакета npm для захвата корневого пути электронного приложения.

$ 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

преамбула

Это очень старый вопрос, но он, похоже, все еще действует в 2020 году, как и в 2012 году. Я проверил все остальные ответы и не смог найти технику (обратите внимание, что это имеет свои ограничения, но все остальные не применимо в любой ситуации).

GIT + дочерний процесс

Если вы используете GIT в качестве вашей системы контроля версий, проблема определения корня проекта может быть уменьшена до (который я считаю правильным корнем проекта - в конце концов, вы бы хотели, чтобы ваша VCS имела максимально возможную область видимости) :

путь к корню репозитория

Поскольку для этого вам нужно выполнить команду CLI, нам нужно будет запустить дочерний процесс. Кроме того, поскольку корень проекта вряд ли изменится во время выполнения, мы можем использовать синхронную версию child_processAPI модулей при запуске.

Я нашел spawnSync()наиболее подходящим для работы. Что касается фактической команды, которую нужно выполнить git worktree--porcelainвозможностью облегчения синтаксического анализа) - это все, что нам нужно для получения абсолютного корневого пути.

В этом примере я решил вернуть массив путей, потому что может быть несколько рабочих дерев (хотя они могут иметь общие пути), чтобы быть уверенным. Обратите внимание, что, поскольку мы используем команду CLI, для shellпараметра должна быть установлена ​​опция true(безопасность не должна быть проблемой, поскольку нет ненадежного ввода).

Подход сравнения и запасные варианты

Понимая, что ситуация, в которой VCS может быть недоступен, я включил несколько запасных вариантов после анализа документов и других ответов. Подводя итог, можно сказать, что предлагаемые решения сводятся к (исключая сторонние модули и для конкретного пакета):

| Решение | Преимущество | Главная проблема |
| ------------------------ | ----------------------- | -------------------------------- |
| `__filename` | указывает на файл модуля | относительно модуля |
| `__dirname` | указывает на модуль dir | такой же как `__filename` |
| `node_modules` прогулка по дереву | почти гарантированный корень | сложная прогулка по дереву, если вложена |
| `path.resolve (". ")` | root, если CWD - root | такой же как `process.cwd ()` |
| `process.argv [1]` | такой же как `__filename` | такой же как `__filename` |
| `process.env.INIT_CWD` | указывает на `npm run` dir | требует запуска `npm` && CLI |
| `process.env.PWD` | указывает на текущий каталог | относительно (является) запуска DIR |
| `process.cwd ()` | такой же как `env.PWD` | `process.chdir (путь)` во время выполнения |
| `require.main.filename` | root если `=== module` | не работает на `require`d модулях |

Из приведенной выше сравнительной таблицы наиболее универсальными являются два подхода:

  • require.main.filenameкак простой способ получить root, если require.main === moduleвстречено
  • node_modulesПредложенная недавно прогулка по дереву использует другое предположение:

если каталог модуля имеет каталог node_modulesвнутри, скорее всего, он является корневым

Для основного приложения он получит корень приложения, а для модуля - его корень проекта.

Отступление 1. Прогулка по деревьям

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

/**
 * @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. Основной модуль

Вторая реализация тривиальна

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

Реализация

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

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

Недостатки

Наиболее очевидным является установка и инициализация GIT, что может быть нежелательным / неправдоподобным (примечание: установка GIT на производственных серверах не редкость и небезопасна ). Может быть опосредовано откатами, как описано выше.

Ноты

  1. Пара идей для дальнейшего расширения подхода 1:
    • ввести конфиг как параметр функции
    • export функция, чтобы сделать его модулем
    • проверить, установлен ли GIT и / или инициализирован

Ссылки

  1. git worktree ссылка
  2. spawnSync ссылка
  3. require.main ссылка
  4. path.dirname() ссылка


-1

Пытаться path._makeLong('some_filename_on_root.js');

пример:

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

Это вернет полный путь от корня приложения вашего узла (та же самая позиция в package.json)


-1

Просто используйте:

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

это прекрасно работает! path.resolve (".") также работает
Ноэль Шенк

Это дает только текущий каталог, который не может быть корневым каталогом.
Орад

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.