对同一台服务器上的多个工作区使用共享的 npm node_modules/
Using a shared npm node_modules/ for multiple workspaces on the same server
我们的 Jenkins/CI 服务器 运行 每天为我们的 node/js 项目构建数百个,我希望能够 运行 每个构建完全干净的工作区。但是,npm install
步骤可能需要 10 分钟以上,这实在是太慢了。相反,由于我们的 npm 依赖项仅针对少量构建(约占所有构建的 1%)发生变化,我只想 运行 npm install
每次 npm-shrinkwrap.json
更改一次(检查每次构建时的 md5sum)。如果 shrinkwrap 文件没有改变,使用缓存的 node_modules/
目录。
如果我复制缓存的 node_modules/
,这个计划就足够了,但是即使这个操作也可能需要一分钟。为了进一步优化我们的构建时间,我希望能够符号链接到缓存 node_modules/
,这应该会大大提高我们的整体构建性能。
ln -s /path/to/cache/ /path/to/workspace/node_modules
但是,在依赖关系树的多个级别存在依赖关系的情况下,简单地符号链接到缓存路径是行不通的。例如,我们的顶级项目同时依赖于 gulp
和 gulp-util
。顶级依赖也依赖于 gulp-util
。在 npm install
之后,gulp-util
将安装在顶层 node_modules/
但不会安装在 node_modules/gulp/node_modules
.
如果依赖项存在于本地工作区(即真实目录 /path/to/workspace/node_modules/
),那么 node_modules/gulp
中 require('gulp-util')
的任何实例都将(我认为)递归依赖树直到找到合适的 gulp-util
模块。也就是说,它开始查找 /path/to/workspace/node_modules/gulp/node_modules/gulp-util
,没有找到任何东西,然后查找 /path/to/workspace/node_modules/gulp-util
,找到合适的模块,导入它并继续。
但是,当这是一个符号链接时,我会收到如下错误:
module.js:339
throw err;
^
Error: Cannot find module 'gulp-util'
at Function.Module._resolveFilename (module.js:337:15)
at Function.Module._load (module.js:287:25)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/path/to/cache/gulp/index.js:4:15)
at Module._compile (module.js:435:26)
at Object.Module._extensions..js (module.js:442:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
我假设它尝试与其他版本做同样的事情,但我不明白为什么它找不到 gulp-util
。无论是在 /path/to/workspace/node_modules/gulp-util
还是 /path/to/cache/gulp-util
中查找,它都应该找到模块并能够导入它。
我尝试通过手动安装模块 gulp/node_modules/gulp-util
来解决这个问题,但是我遇到了很多这样的错误,并且在构建服务器上手动处理这个问题是不可行的。写一些代码来搜索这种类型的依赖项并安装它们是可能的,但感觉这样做是错误的。
npm 一定有某种方式支持这样的工作流程,对吧?我错过了一些明显的东西吗?我是否掩盖了文档中的某些内容?
感谢@amol-m-kulkarni here 发布的回答(上面@darko-rodic 提供的有用参考),我意识到我的错误。
If the given module is not a core modules(e.g. http, fs, etc.),
Node.js will then begin to search for a directory named, node_modules.
It will start in the current directory (relative to the
currently-executing file in Node.JS) and then work its way up the
folder hierarchy, checking each level for a node_modules folder. Once
Node.JS finds the node_modules folder, it will then attempt to load
the given module either as a (.js) JavaScript file or as a named
sub-directory; if it finds the named sub-directory, it will then
attempt to load the file in various ways. So, for example
我的错误在于我给缓存路径的名称。由于它被命名为 /path/to/cache
,require
在路径中遇到的最后一个 node_modules
目录后停止向上查找。在这种情况下,它停在 /path/to/cache/gulp/node_modules
,并没有意识到 /path/to/cache/gulp-util
应该在搜索中被考虑。
我通过将缓存重命名为 /path/to/cache/node_modules
来修复此问题,因此 require
将继续搜索直到达到该级别,随后将找到 /path/to/cache/node_modules/gulp-util
.
我将再次参考文档,看看我是否应该清楚这一点。
我们的 Jenkins/CI 服务器 运行 每天为我们的 node/js 项目构建数百个,我希望能够 运行 每个构建完全干净的工作区。但是,npm install
步骤可能需要 10 分钟以上,这实在是太慢了。相反,由于我们的 npm 依赖项仅针对少量构建(约占所有构建的 1%)发生变化,我只想 运行 npm install
每次 npm-shrinkwrap.json
更改一次(检查每次构建时的 md5sum)。如果 shrinkwrap 文件没有改变,使用缓存的 node_modules/
目录。
如果我复制缓存的 node_modules/
,这个计划就足够了,但是即使这个操作也可能需要一分钟。为了进一步优化我们的构建时间,我希望能够符号链接到缓存 node_modules/
,这应该会大大提高我们的整体构建性能。
ln -s /path/to/cache/ /path/to/workspace/node_modules
但是,在依赖关系树的多个级别存在依赖关系的情况下,简单地符号链接到缓存路径是行不通的。例如,我们的顶级项目同时依赖于 gulp
和 gulp-util
。顶级依赖也依赖于 gulp-util
。在 npm install
之后,gulp-util
将安装在顶层 node_modules/
但不会安装在 node_modules/gulp/node_modules
.
如果依赖项存在于本地工作区(即真实目录 /path/to/workspace/node_modules/
),那么 node_modules/gulp
中 require('gulp-util')
的任何实例都将(我认为)递归依赖树直到找到合适的 gulp-util
模块。也就是说,它开始查找 /path/to/workspace/node_modules/gulp/node_modules/gulp-util
,没有找到任何东西,然后查找 /path/to/workspace/node_modules/gulp-util
,找到合适的模块,导入它并继续。
但是,当这是一个符号链接时,我会收到如下错误:
module.js:339
throw err;
^
Error: Cannot find module 'gulp-util'
at Function.Module._resolveFilename (module.js:337:15)
at Function.Module._load (module.js:287:25)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/path/to/cache/gulp/index.js:4:15)
at Module._compile (module.js:435:26)
at Object.Module._extensions..js (module.js:442:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
我假设它尝试与其他版本做同样的事情,但我不明白为什么它找不到 gulp-util
。无论是在 /path/to/workspace/node_modules/gulp-util
还是 /path/to/cache/gulp-util
中查找,它都应该找到模块并能够导入它。
我尝试通过手动安装模块 gulp/node_modules/gulp-util
来解决这个问题,但是我遇到了很多这样的错误,并且在构建服务器上手动处理这个问题是不可行的。写一些代码来搜索这种类型的依赖项并安装它们是可能的,但感觉这样做是错误的。
npm 一定有某种方式支持这样的工作流程,对吧?我错过了一些明显的东西吗?我是否掩盖了文档中的某些内容?
感谢@amol-m-kulkarni here 发布的回答(上面@darko-rodic 提供的有用参考),我意识到我的错误。
If the given module is not a core modules(e.g. http, fs, etc.), Node.js will then begin to search for a directory named, node_modules.
It will start in the current directory (relative to the currently-executing file in Node.JS) and then work its way up the folder hierarchy, checking each level for a node_modules folder. Once Node.JS finds the node_modules folder, it will then attempt to load the given module either as a (.js) JavaScript file or as a named sub-directory; if it finds the named sub-directory, it will then attempt to load the file in various ways. So, for example
我的错误在于我给缓存路径的名称。由于它被命名为 /path/to/cache
,require
在路径中遇到的最后一个 node_modules
目录后停止向上查找。在这种情况下,它停在 /path/to/cache/gulp/node_modules
,并没有意识到 /path/to/cache/gulp-util
应该在搜索中被考虑。
我通过将缓存重命名为 /path/to/cache/node_modules
来修复此问题,因此 require
将继续搜索直到达到该级别,随后将找到 /path/to/cache/node_modules/gulp-util
.
我将再次参考文档,看看我是否应该清楚这一点。