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

Є кілька способів підходу до цього, кожен зі своїми плюсами і мінусами:

need.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 або бігом мокко випробування, цей метод не вийде .

глобальний.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

додаток-root-шлях

Щоб вирішити цю проблему, я створив модуль вузла під назвою 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і ви золото. Я поєдную це з моїм модулем примусового контуру , який запобігає випадковому завантаженню програми без NODE_PATHнабору. Для ще більшого контролю за виконанням змінних умов навколишнього середовища див. Checkenv .

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

[додано 4/6/16] Інший дійсно перспективний модуль, який намагається вирішити цю проблему, є хвилястим .

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

Якщо ви хочете використовувати кореневий каталог запущеного процесу, ви, ймовірно, хочете використовувати process.cwd().

Якщо ви хочете передбачуваності та надійності, то, ймовірно, вам потрібно встановити вимогу програми, щоб встановити певну змінну середовища. Ваш додаток шукає MY_APP_HOME(або що завгодно), і якщо він є, а програма існує в цьому каталозі, тоді все добре. Якщо він не визначений або каталог не містить вашої програми, він повинен вийти з помилкою, яка спонукає користувача створити змінну. Його можна встановити як частину процесу встановлення.

Ви можете читати змінні середовища у вузлі з чимось подібним process.env.MY_ENV_VARIABLE.

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; 

таким чином у вас будуть всі каталоги проектів відносно цього файлу;)

найпростіший спосіб отримати глобальний корінь ( якщо припустимо, що ви використовуєте 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')який дуже добре працює для цієї мети

Я виявив, що це працює для мене постійно, навіть коли додаток викликається з підпапки, як це може бути з деякими тестовими рамками, такими як Mocha:

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

Чому це працює:

Під час виконання вузол створює реєстр повних шляхів усіх завантажених файлів. Модулі завантажуються спочатку, і, таким чином, у верхній частині цього реєстру. Вибравши перший елемент реєстру та повернувши шлях до каталогу 'node_modules', ми зможемо визначити корінь програми.

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

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

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

Усі ці "кореневі паси" в основному потребують вирішення якогось віртуального шляху до справжнього купового шляху, тож, можливо, вам варто подивитися path.resolve?

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

Настільки ж просто, як додати цей рядок до свого модуля в root, зазвичай це app.js

global.__basedir = __dirname;

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

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

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

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

Метод, який я вважаю корисним при використанні експресу, - це додати наступне до app.js перед тим, як встановити будь-який з інших ваших маршрутів

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

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

Не потрібно використовувати глобали, і у вас є шлях кореневого каталогу як властивість об'єкта запиту.

Це працює, якщо ваш app.js знаходиться в корені вашого проекту, який за замовчуванням є.

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

global.__basedir = __dirname;

Це встановлює глобальну змінну, яка завжди буде еквівалентною базовому режиму вашого додатка. Використовуйте його так само, як і будь-яку іншу змінну:

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

Просте ...

Я знаю, що це вже пізно. Але ми можемо отримати кореневу 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

На ньому є INIT_CWDвласність process.env. З цим я зараз працюю у своєму проекті.

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

Щасти...

якщо ви хочете визначити корінь проекту з запущеної програми node.js, ви можете просто просто.

process.mainModule.path

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

mainDir = __dirname;

Потім використовуйте його в будь-якому потрібному вам файлі:

console.log('mainDir ' + mainDir);

• mainDir визначається в усьому світі, якщо вам це потрібно лише в поточному файлі - використовуйте __dirname замість цього.
• Основний файл, як правило , в кореневій папці проекту і названий як main.js, index.js, gulpfile.js.

Я цим користуюся.

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

var BASE_DIR = __dirname.replace(/^(.*\/mymodule)(.*)$/, '$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

Це дозволить зменшити дерево каталогів, поки воно не містить 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у поверненому шляху, оскільки це означає, що він міститься в вкладеному пакеті встановлення.

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

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

Отримайте всі шляхи в основних модулях і відфільтруйте ті, що мають "node_modules", після чого отримайте перший із списку шляхів, що залишилися. Несподівана поведінка не призведе до помилок, а лише до помилки undefined.

Для мене добре працює, навіть коли дзвонить, тобто $ mocha.

Створіть функцію в 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'));

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

Я знаю, старе питання, проте жодне питання не потрібно згадувати 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 || '';
    }
}; 

Пошук кореневого шляху електронного додатка може стати складним. Тому що кореневий шлях відрізняється для основного процесу та рендерінга за різних умов, таких як виробництво, розробка та упаковані умови.

Я написав npm пакунок electron-root-path, щоб захопити кореневий шлях електронної програми.

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

Це зробить:

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

Це працює для мене

process.env.PWD

Преамбула

Це дуже давнє запитання, але, схоже, все ще вдарило по нерву в 2020 році, як і в 2012 році. Я перевірив усі інші відповіді і не міг знайти теніку (зауважте, що це має свої обмеження, але всі інші не застосовується також у будь-якій ситуації).

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

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

відновлення кореневого шляху до сховища

Оскільки для цього вам потрібно виконати команду CLI, нам знадобиться породити дочірній процес. Крім того, оскільки кореневий проект малоймовірно змінить середину виконання, ми можемо використовувати синхронну версію child_processмодулів API при запуску.

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

У зразку я вирішив повернути масив контурів, тому що може бути більше одного робочого дерева (хоча вони, ймовірно, мають спільні шляхи) просто для впевненості. Зауважте, що, використовуючи команду CLI, shellслід встановити параметр true(безпека не повинна бути проблемою, оскільки немає ненадійного вводу).

Підхід порівняння та резервні наслідки

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

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

З наведеної вище таблиці порівняння найбільш універсальними є два підходи:

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

якщо в каталозі модуля є node_modulesdir всередині, він, ймовірно, є коренем

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

Запасний 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));
    };

Резервний 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:
   • ввести config як функціональний параметр
   • export функція зробити його модулем
   • перевірити, чи встановлено та / або ініціалізовано GIT

Список літератури

1. git worktree довідник
2. spawnSync довідник
3. require.main довідник
4. path.dirname() довідник

Простий: require('path').resolve('./')

Спробуйте path._makeLong('some_filename_on_root.js');

приклад:

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

Це поверне повний шлях від кореня програми вашого вузла (те саме положення package.json)

Просто використовуйте:

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

path.dirname(process.mainModule.filename);