通过将它包含在package.json中,可以将node.js本身作为 dev-dependency 放置在基于节点的项目中,如
npm install --save-dev node@12.7
在这种情况下,显然所有基于节点的工具(如eslint或babel等)都将使用安装在<project_root>/node_modules/.bin
中的那个版本的节点
下面是一个示例package.json
{
"name": "test-node",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "node -v",
"build": "node build.js"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"node": "12.7.0"
}
}
测试似乎可行
$ npm install
$ echo "console.log(process.version)" > build.js
$ npm test
> test-node@1.0.0 test /Users/gregg/temp/test-node
> node -v
v12.7.0
$ npm run build
> test-node@1.0.0 build /Users/gregg/temp/test-node
> node build.js
v12.7.0
$ node -v
v12.6.0
您可以看到我的常规路径中安装了节点12.6,但是上面的命令使用了节点12.7。
在特定项目的开发环境中使用已知的确切工作版本的节点似乎具有明显的优势。
是否有避免这种情况的具体客观原因?
我的头顶上
它使依赖关系更大。节点约为18meg下载
更大是否更糟虽然是一个观点问题,但这实际上只是一个观察,而不是避免的理由。
这是更新的另一项依赖
那又似乎只是一种意见。所有依赖项都有版本。争辩说不应该对任何依赖项进行版本控制,这是一条不应该对所有依赖项进行版本控制的说法。
这就是我能想到的全部。是否有一些客观的反对意见,例如“如果这样做,X会因为Y而破裂”?
再次,我不是要征求意见。我正在寻找不这样做的具体客观原因。一个项目需要节点8,另一个需要节点11。确定设置环境变量或路径也可以解决该问题,但是需要警惕,工作或额外的知识。忘记了,您将获得必须跟踪的错误消息。它还需要更多的文档或更多的知识,因为将所需的节点版本放在项目本身中意味着它可以正常工作。
还要重申一下,这是一个 dev-dependency ,因此只有运行生成库,发行版或运行测试的工具所需的依赖项。当然,在大多数情况下,将其包含为 non-dev 依赖项在客观上是不利的。
注意:有人会建议使用engines
。
引擎是正交设置。这就是说运行库需要什么版本的节点,而不是构建库或运行测试需要什么版本的节点。换句话说,engines
是一个依赖设置,而不是 DEV 依赖设置。
注释2:有人会建议使用nvm
,但从客观上讲会更糟。
在所有基于节点的项目中,要进行开发,您必须运行npm install
。
通过直接添加node
作为依赖项,不需要额外的知识。键入npm install
后,就可以开始工作了。如果不添加它,新开发人员必须使用Google“如何处理多个节点版本”,这在不同平台之间是不同的。为什么在添加dev依赖项时使它们变得更困难,并需要额外的知识呢?
此外,nvm很繁琐。考虑2个需要不同版本节点的项目。有了以上解决方案,工作流程就是
cd projectThatNeedsNode8
npm run build
npm test
cd projectThatNeedsNode12
npm run build
npm test
使用基于nvm的解决方案,几乎可以保证是这种工作流程
cd projectThatNeedsNode8
npm run build
# error, need node 8
nvm use 8
npm run build
npm test
cd projectThatNeedsNode12
npm run build
# error, need node 12
nvm use 12
npm run build
npm test
除了明显的错误外,您需要另一个版本的节点的可能性可能不到10%。该错误很可能是某些堆栈转储或行号,而没有迹象表明真正的问题是节点的版本错误。
换句话说,如果将节点直接添加为 dev 依赖项是设置 dev 依赖项的标准方法,那么nvm
可能就不存在了。
是的,显然您可以添加更多晦涩的技巧,以便每次切换目录时都能运行nvm。仍然不只是将节点列为开发依赖项,这仍然不是客观原因。