我应该将所有子包保存在package.json中的单个版本中吗？

Question

我的项目使用的第三方库已将其功能拆分为多个导入的包，以便项目可以安装所需的内容。在package.json中，为不同的子包提供了几个条目，例如......

  "dependencies": {
    "@lib/dogs": "^1.0.3",
    "@lib/cats": "^1.0.3",
    "@lib/iguanas": "^1.0.3"
    ...lots more of the same...
  }

我不想花时间考虑兼容性问题，如果其中一个子软件包通过semver-range-picking安装不同版本的＃或其他开发人员通过增加版本来修复问题一个子包。我怀疑如果子包版本不同步存在一些bug的风险，即使包维护者的意图是尊重破坏其版本控制中的更改的意义。默认情况下，将所有子包放在同一版本上似乎更简单。

我是否应该尝试强制（或至少宣传）子包具有相同的版本？

Answer 1

推广，但不执行。

使用Caret Ranges的当前设置是使用--save标志安装时的默认设置，原因是：它是用于正确遵循semver的依赖项的最灵活和最强大的范围约定。这意味着只要有人update将您的模块作为他们的依赖关系，它就会自动将其子依赖关系推向与^之后明确指定的版本向后兼容的最新版本。

由于这一点，以及scoped packages没有相互依赖性的事实，因为它们的行为与正常的依赖关系完全相同，因此为它们中的每一个留下相同的插入符号范围应该足以避免默认情况下的兼容性问题。 / p>

不要保护开发者自己

在考虑如何处理兼容性问题时要遵循的一个好方法是避免反模式“保护开发人员自己”。在这种情况下，您建议使用锁定来阻止第三方编辑依赖项的相对版本，以避免兼容性问题。这是一个非常模糊的目标，因为你还没有遇到任何问题，正如你所指出的那样。

有时，是的，开发人员可能不知道他们在做什么，在这种情况下，他们可能会避免篡改您的默认依赖版本，但有时他们确实知道，当开发人员知道他们可以解决时，这可能会令人沮丧一个错误，不必要地阻止这样做。所以握住他们的手，不要把它们铐住。

npm已经选择避免这种反模式，你也应该这样做。

如果第三方开发人员选择使用您的模块作为依赖项，那么他们应该具有默认的自由度，可以通过使用package-lock.json等功能来通过npm管理其子依赖项，从而解锁一个非常干净的模块用于精确管理子依赖版本的模式，无需编辑其依赖项的源代码。

总之，您现在拥有的是一种非常干净和灵活的方法，遵循常见的约定，而不是为了限制第三方开发人员。