安装 npm 模块作为自身的 devDependency

Question

假设我制作了一个名为 foo 的 TDD 工具，我想使用 foo v1 来帮助我开发 foo v2。

但是当我npm install --save-dev foo@^1.0.0 时，npm 说“拒绝将 foo 安装为自身的依赖项”。

1. 为什么 npm 拒绝这样做？
2. 我能做些什么呢？

到目前为止我得到的解决方法（以及为什么它们不够好）：

• 解决方法 1： 只需使用相对要求直接要求相关脚本，例如require('../lib')（这就是mocha does it，到目前为止我一直是这样做的）。

  • 但是如果您正在开发模块的新版本、添加功能，甚至可能删除旧功能，那么您不仅需要不断更改测试的内容，还需要更改它们的format，因为你实际上是在使用你正在做的事情来测试你正在做的事情。如果它坏了，你必须在没有测试的情况下在黑暗中修复它来指导你。使用 settled v1 API 来 tdd-ing 新的 v2 API 会更好。

• 解决方法 2： 以不同的名称将模块的副本发布到 npm，例如“foo-clone”。 （然后你可以安装 foo-clone 作为 foo 的 devDependency。）

  • 但是这看起来很乱，而且是对 npm 的误用。无论如何，如果安装一个精确的克隆可以工作，那么 npm 允许我安装 [an old version of] foo 作为 foo 的 devDependency 会有什么危害？

Answer 1

这是解决方法 2 的更好替代方案。

---

让我们假设您只需要在开发的早期阶段使用这种依赖关系。因此，在发布第一个生产就绪版本之前，您将摆脱它，例如通过采用mocha 解决方案（使用当前稳定版本进行自我测试）。

在这种情况下，您可以临时重命名您的包（即使用 -dev 后缀），而不是发布重复的包。

为了保证这个重命名的包不会被发布，你也可以添加private flag。

因此，您的 dev package.json 将如下所示：

{
  "name": "mytdd-dev",
  "version": "2.0.0-dev",
  "private": true,
  ...
  "devDependencies": {
    "mytdd": "1.x.x",
    ...
  },
  ...
}

然后，当您的包准备好发布第一个版本时，您将删除所有 -dev 后缀、private 标志和 dev 对先前版本的依赖。

此解决方案的唯一问题是您无法将 TDD 工具的早期开发版本发布到 npm（只要您依赖以前的版本）。

---

如果安装一个精确的克隆可以工作，那么在 npm 中允许我安装 [an old version of] foo 作为 foo 的 devDependency 会有什么危害

我认为这是针对循环依赖的安全预防措施。

如果你认为 npm 应该在这里为 devDependencies 做一个例外，这对我来说听起来很合理，那么你应该将你的建议发布到 npm issues tracker。