我是否应该将所有子包保存在package.json中的单个版本中？
我的项目使用的第三方库已经将其function分割为多个导入的包，以便项目可以安装它所需的东西。 在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的风险，即使包维护者的意图是尊重破坏版本变化的含义。 只是默认情况下，所有的子软件包都在相同的版本上似乎更简单。
我应该尝试执行（或者至less是提升）子包具有相同的版本吗？
促进，但不强制执行。
使用Caret Ranges的当前设置是使用--save标志进行安装时使用的默认值，原因是：它是用于正确遵循semver约定的依赖性的最灵活和最强健的范围。 这意味着每当有人update你的模块作为它们的依赖时，它会自动将它们的子依赖碰到与^之后明确指定的最后版本兼容的最新版本。
正因为如此， 范围化软件包没有相互依赖关系，因为它们的行为与正常依赖关系相同，所以为每个范围保留相同的插入符号范围应该足以避免默认情况下的兼容性问题。
不要保护开发者自己
在考虑如何处理兼容性问题时，一个好的方法是避免“保护开发人员不受自身约束”的反模式。 在这种情况下，您build议放置一个锁，防止第三方编辑您的依赖项的相关版本，以避免兼容性问题。 这是一个非常模糊的目标，因为你还没有真正遇到任何问题，正如你已经指出的那样。
有时候，开发人员可能不知道他们在做什么，在这种情况下，他们可能会避免篡改默认的依赖版本，但有时他们确实知道，而且当开发人员知道他们可以解决错误并且被不必要地阻止这样做。 所以握住他们的手，不要袖手旁观。
npm已经select了避免这种反模式，你也应该这样做。
如果第三方开发者select使用模块作为依赖关系，那么他们应该拥有默认的自由度，通过使用像package-lock.json这样的function，通过npm来pipe理他们的子依赖关系，这样就可以精确地解锁一个非常干净的模式pipe理子依赖版本而不编辑其依赖关系的源代码。
总而言之，你现在拥有的是一个非常干净灵活的方法，按照惯例，而不是为了约束第三方开发者。