Question

我有一个nodejs项目，在我自己的模块上有一些依赖项。根据npm目前的最佳实践，这些依赖关系使用npm link / npm link $package-name命令表示，因此项目现在在其node_modules中有一些符号链接。在当地工作。

然而，当我将该项目推送到github时，链接将保留为链接，这意味着克隆它的其他人（很可能）会看到断开的链接。另一点是我将node_modules目录全部推送到github - 这是可以的，到目前为止克隆来自github现在为您提供了一个完整的项目实例，并解决了所有依赖关系，但另一方面我突然有了很多在我的回购中第三方的东西。

处理这种情况的最佳做法是什么？

编辑我刚才意识到的一件事是，无论如何检查依赖关系是不正确的 - 可能有一些二进制文件需要以特定于平台的方式安装。所以你永远不会检查你的依赖项？

Answer 1

不要在源存储库中包含node_modules目录。 Git用于源代码，而不是构建的发行版。这是几十年来最好的做法。忽略你偶尔会把构建工件放入git中的时髦。他们错了，他们只是没有感受到足够的痛苦而尚未意识到这一点。除了从合理的方法论角度来看不正确之外，当你的项目包含任何具有每个平台编译的C组件的扩展时，包括git中的node_modules都会失败。这将无法至少要求克隆回购的用户至少npm rebuild进行修复，此时您也可以让他们按npm install作为$Deity。< / p>

Answer 2

首先，不要在git项目中包含其他节点模块

cd ~/your_module && echo "/node_modules" >> .gitignore

其次，如果您的模块具有依赖关系，只需在package.json中声明它们。以下是我的burro模块

中的示例

// package.json
{
  // ...
  "devDependencies": {
    "mocha": "~1.8.1",
    "hiccup": "~0.1.4"
  },
  "dependencies": {
    "bun": "~0.0.5"
  }
}

对于它的价值，我实际上并没有使用npm link功能;我分别构建/测试我的所有模块。如果你想要其他的例子，你可以在我的github repositories上看到很多它们。

我的基本工作流程如下：

补丁模块A
模块A上的凹凸版本
npm publish模块A
模块B中模块A的凹凸版本依赖性
re - npm install模块B中的模块A
补丁模块B使用新版本的模块A（如果需要）
模块B上的凹凸版本
npm publish模块B

npm link很方便，但我认为它可以启用/鼓励模块之间过于紧密的耦合。我坚信“做一件事，做得好”的口头禅并在编写我的所有模块时牢记这一点。使用此工作流程将有助于保持您的功能良好的封装，社区将喜欢您的发布。

至于github位，npm并不关心这一点。作为一种习惯，在我npm publish发布之前，我将始终使用模块版本标记该提交。这是一个例子

在package.json
git commit -m "bump to version 0.1.5"
git tag v0.1.5
git push origin master --tags
npm publish

现在npmjs.org和github.com都同意相同的版本。从任一来源下载您的软件包的用户总是会得到相同的东西。

nodejs，github，npm和符号链接

2 个答案: