除了process.cwd()之外,是否有其他方法来获取当前项目根目录的路径名。Node是否实现了ruby的属性Rails.root之类的东西。我要找的是稳定可靠的东西。
当前回答
我发现这对我来说是一致的,即使应用程序是从子文件夹中调用的,因为它可以与一些测试框架,如Mocha:
process.mainModule.paths[0].split('node_modules')[0].slice(0, -1);
为什么有效:
在运行时,节点创建所有加载文件的完整路径的注册表。模块首先加载,因此位于注册表的顶部。通过选择注册表的第一个元素并返回'node_modules'目录之前的路径,我们可以确定应用程序的根目录。
它只有一行代码,但为了简单起见(我的),我把它黑盒到一个NPM模块:
https://www.npmjs.com/package/node-root.pddivine
享受吧!
编辑:
的过程。mainModule从v14.0.0开始已弃用
使用要求。主要:
require.main.paths [0] .split(“node_modules”)[0]。片(0,1);
其他回答
序言
这是一个非常古老的问题,但它似乎在2020年和2012年一样触动了人们的神经。 我检查了所有其他的答案,没有找到下面提到的技巧(它有自己的局限性,但其他的也不是适用于所有的情况):
Git +子进程
如果你使用Git作为你的版本控制系统,确定项目根的问题可以简化为(我认为项目的正确根-毕竟,你会希望你的VCS有尽可能充分的可见范围):
检索存储库根路径
由于您必须运行CLI命令来执行此操作,因此我们需要生成一个子进程。此外,由于项目根不太可能在运行时中期更改,我们可以在启动时使用child_process模块的同步版本。
我发现spawnSync()最适合这项工作。至于实际要运行的命令,检索根目录的绝对路径所需要的就是git工作树(带有——porcelain选项,以便于解析)。
在答案后面的示例中,我选择返回一个路径数组,因为可能存在多个工作树(尽管它们可能具有公共路径)。注意,当我们使用CLI命令时,shell选项应该设置为true(安全性不应该成为问题,因为没有不可信的输入)。
方法比较和后备
了解到VCS可能无法访问的情况,在分析了文档和其他答案后,我包含了一些备用方案。建议解决方案可归纳为(不含第三方模块和包):
Solution | Advantage | Main Problem |
---|---|---|
__filename |
points to module file | relative to module |
__dirname |
points to module dir | same as __filename |
node_modules tree walk |
nearly guaranteed root | complex tree walking if nested |
path.resolve(".") |
root if CWD is root | same as process.cwd() |
process.argv\[1\] |
same as __filename |
same as __filename |
process.env.INIT_CWD |
points to npm run dir |
requires npm && CLI launch |
process.env.PWD |
points to current dir | relative to (is the) launch dir |
process.cwd() |
same as env.PWD |
process.chdir(path) at runtime |
require.main.filename |
root if === module |
fails on require d modules |
从上面的对比表来看,以下方法是最普遍的:
require.main.filename作为获取根文件的简单方法。Main ===模块满足 最近提出的Node_modules树遍历使用了另一个假设:
如果模块的目录中有node_modules dir,那么它很可能是根目录
对于主应用程序,它将获得应用程序根,而对于一个模块——它的项目根。
回退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并不少见,也不是不安全的)。如上所述,可以通过回退来调节。
简单:
require('path').resolve('./')
就像在根目录中添加这一行到你的模块一样简单,通常是app.js或app.ts。
global.__basedir = __dirname;
然后所有模块都可以访问_basedir。
注意:对于typescript实现,遵循上面的步骤,然后你将能够使用global.__basedir使用根目录路径
老问题,我知道,但是没有问题提到使用progress.argv。argv数组包含完整的路径名和文件名(带或不带.js扩展名),用作节点执行的参数。因为它也可以包含标志,所以必须对其进行过滤。
这不是一个你可以直接使用的例子(因为使用我自己的框架),但我认为它给了你一些想法如何做到这一点。我还使用缓存方法来避免调用这个函数对系统造成太大的压力,特别是在没有指定扩展名(并且需要文件存在检查)的情况下,例如:
node myfile
or
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 || '';
}
};
解决这个问题有很多种方法,每种方法都有其优缺点:
require.main.filename
从http://nodejs.org/api/modules.html:
当一个文件直接从Node运行时,require。Main被设置为它的模块。这意味着您可以通过测试require来确定文件是否已经直接运行。Main ===模块 因为module提供了一个filename属性(通常等价于__filename),当前应用程序的入口点可以通过检查require.main.filename来获得。
如果你想要应用的基目录,你可以这样做:
const { dirname } = require('path');
const appDir = dirname(require.main.filename);
优点与缺点
这种方法在大多数情况下都很有效,但如果你使用pm2之类的启动器或运行mocha测试,这种方法就会失败。这在使用Node.js ES模块时也不起作用。Main不可用。
module.paths
Node将所有模块搜索路径发布到module.paths。我们可以遍历这些,选择第一个解出来的。
async function getAppPath() {
const { dirname } = require('path');
const { constants, promises: { access } } = require('fs');
for (let path of module.paths) {
try {
await access(path, constants.F_OK);
return dirname(path);
} catch (e) {
// Just move on to next path
}
}
}
优点与缺点
这有时可以工作,但在包中使用时不可靠,因为它可能返回包安装所在的目录,而不是应用程序安装所在的目录。
使用全局变量
Node有一个全局命名空间对象,叫做global -你附加到这个对象上的任何东西都将在你的应用程序中的任何地方可用 ),你可以只定义一个全局变量:
// 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
为了解决这个问题,我创建了一个名为app-root-path的节点模块。用法很简单:
const appRoot = require('app-root-path');
const myModule = require(`${ appRoot }/lib/my-module.js`);
app-root-path模块使用了几种技术来确定应用程序的根路径,考虑到全局安装的模块(例如,如果你的应用程序运行在/var/www/,但模块安装在~/.nvm/ v2 .x.x/lib/node/)。它不会在100%的情况下工作,但在大多数常见的情况下都会工作。
优点与缺点
在大多数情况下不需要配置即可工作。还提供了一些很好的额外方便的方法(参见项目页面)。最大的骗局是,如果出现以下情况,它就不会起作用:
你用的是启动器,比如pm2 并且,该模块没有安装在你的应用程序的node_modules目录中(例如,如果你全局安装它)
您可以通过设置APP_ROOT_PATH环境变量或在模块上调用. setpath()来解决这个问题,但在这种情况下,您可能最好使用全局方法。
NODE_PATH环境变量
如果你正在寻找一种方法来确定当前应用程序的根路径,上述解决方案之一可能最适合你。另一方面,如果您试图解决可靠地加载应用程序模块的问题,我强烈建议查看NODE_PATH环境变量。
Node的Modules系统在不同的位置寻找模块。其中一个位置是process.env. exe。NODE_PATH点。如果您设置了这个环境变量,那么您就可以使用标准模块加载器要求模块,而不需要进行任何其他更改。
例如,如果你将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。
有一个问题:NODE_PATH必须在节点应用程序之外设置。你不能做process.env之类的事情。NODE_PATH = path.resolve(__dirname),因为模块加载器在应用程序运行之前缓存了它要搜索的目录列表。
[增加4/6/16]另一个非常有前途的模块,试图解决这个问题是波浪。
推荐文章
- 有没有办法修复包锁。json lockfileVersion所以npm使用特定的格式?
- 如何使用npm全局安装一个模块?
- 实时http流到HTML5视频客户端的最佳方法
- 使用node.js下载图像
- Node.js Express中的HTTP GET请求
- Node.js:将文本文件读入数组。(每一行都是数组中的一项。)
- npm犯错!错误:EPERM:操作不允许,重命名
- Node Sass还不支持当前环境:Linux 64位,带false
- 我如何添加环境变量启动。VSCode中的json
- 解析错误:无法读取文件“…/tsconfig.json”.eslint
- 在Node.js中'use strict'语句是如何解释的?
- 当WebSockets可用时,为什么要使用AJAX ?
- 使用过程。TypeScript中的env
- 如何找到哪些承诺未处理在Node.js UnhandledPromiseRejectionWarning?
- 如何卸载Yarn