我应该在 package.json 中将所有子包保留在一个版本中吗？
Should I keep all sub-packages on a single version in package.json?
我的项目使用了一个第 3 方库，该库已将其功能拆分为多个导入包，以便项目可以只安装它需要的东西。在 package.json 中，针对不同的子包存在多个条目，例如...
"dependencies": {
"@lib/dogs": "^1.0.3",
"@lib/cats": "^1.0.3",
"@lib/iguanas": "^1.0.3"
...lots more of the same...
}
如果其中一个子包安装的版本与其他子包不同，我不想花时间考虑兼容性问题#一个子包。我怀疑如果子包版本不同步，则存在一些错误风险，即使包维护者的意图是尊重其版本控制中破坏性更改的含义。默认情况下将所有子包都放在同一个版本上似乎更简单。
我应该尝试强制（或至少提倡）子包具有相同的版本吗？
提倡，但不强制执行。
您当前使用 Caret Ranges 的设置是使用 --save 标志安装时的默认设置，原因是：它是用于正确遵循的依赖项的最灵活和最强大的范围semver 约定。这意味着每当有人 update 将你的模块作为他们模块的依赖项时，它会自动将他们的子依赖项升级到最新版本，该版本与 ^ 之后明确指定的版本向后兼容。
正因为如此，而且 scoped packages 没有相互依赖性，因为它们的行为与正常的依赖性相同，为它们中的每一个留下相同的插入符号范围应该已经足以避免默认情况下的兼容性问题.
不要保护开发者免受他们自己的伤害
考虑如何处理兼容性问题时要遵循的一个好方法是避免 "protecting developers from themselves." 的反模式在这种情况下，您建议放置一个锁以防止第 3 方编辑相关版本您的依赖项，以避免兼容性问题。这是一个非常模糊的目标，因为正如您所指出的那样，您实际上 运行 还没有解决任何问题。
有时，是的，开发人员可能不知道他们在做什么，在这种情况下，他们可能会避免篡改您的默认依赖项版本，但有时他们确实知道，当开发人员知道他们在做什么时，这可能会令人沮丧可以解决 bug 并且被不必要地阻止这样做。所以握住他们的手，不要铐住他们。
npm 已经选择避免这种反模式，你也应该这样做。
如果第 3 方开发人员选择将您的模块用作依赖项，他们应该拥有默认的自由度，可以使用 package-lock.json 等功能通过 npm 管理其子依赖项，这会解锁一个非常简洁的模式，无需编辑其依赖项的源代码即可精确管理子依赖项版本。
总而言之，您现在拥有的是一种非常简洁和灵活的方法，它遵循通用约定并且不会特意限制第 3 方开发人员。
我的项目使用了一个第 3 方库，该库已将其功能拆分为多个导入包，以便项目可以只安装它需要的东西。在 package.json 中，针对不同的子包存在多个条目，例如...
"dependencies": {
"@lib/dogs": "^1.0.3",
"@lib/cats": "^1.0.3",
"@lib/iguanas": "^1.0.3"
...lots more of the same...
}
如果其中一个子包安装的版本与其他子包不同，我不想花时间考虑兼容性问题#一个子包。我怀疑如果子包版本不同步，则存在一些错误风险，即使包维护者的意图是尊重其版本控制中破坏性更改的含义。默认情况下将所有子包都放在同一个版本上似乎更简单。
我应该尝试强制（或至少提倡）子包具有相同的版本吗？
提倡，但不强制执行。
您当前使用 Caret Ranges 的设置是使用 --save 标志安装时的默认设置，原因是：它是用于正确遵循的依赖项的最灵活和最强大的范围semver 约定。这意味着每当有人 update 将你的模块作为他们模块的依赖项时，它会自动将他们的子依赖项升级到最新版本，该版本与 ^ 之后明确指定的版本向后兼容。
正因为如此，而且 scoped packages 没有相互依赖性，因为它们的行为与正常的依赖性相同，为它们中的每一个留下相同的插入符号范围应该已经足以避免默认情况下的兼容性问题.
不要保护开发者免受他们自己的伤害
考虑如何处理兼容性问题时要遵循的一个好方法是避免 "protecting developers from themselves." 的反模式在这种情况下，您建议放置一个锁以防止第 3 方编辑相关版本您的依赖项，以避免兼容性问题。这是一个非常模糊的目标，因为正如您所指出的那样，您实际上 运行 还没有解决任何问题。
有时，是的，开发人员可能不知道他们在做什么，在这种情况下，他们可能会避免篡改您的默认依赖项版本，但有时他们确实知道，当开发人员知道他们在做什么时，这可能会令人沮丧可以解决 bug 并且被不必要地阻止这样做。所以握住他们的手，不要铐住他们。
npm 已经选择避免这种反模式，你也应该这样做。
如果第 3 方开发人员选择将您的模块用作依赖项，他们应该拥有默认的自由度，可以使用 package-lock.json 等功能通过 npm 管理其子依赖项，这会解锁一个非常简洁的模式，无需编辑其依赖项的源代码即可精确管理子依赖项版本。
总而言之，您现在拥有的是一种非常简洁和灵活的方法，它遵循通用约定并且不会特意限制第 3 方开发人员。