我们公司有一些 Web 应用程序，它们又依赖于很长的内部创建和托管的 npm 包链（我们使用 JFrog Artifactory），每个包都有自己的依赖项（等等）。每当修复错误或在低级包中实现功能时，当前流程都需要开发人员检查他们的更改，等待 CICD 构建完成并运行测试，更新父包，然后冲洗/重复所有上链的方式（这可能是一个很长的过程）。
这不可能是一个独特的情况，但它极大地影响了我们的生产力，并鼓励单体包开发来限制要更新的包数量，而不是适当的代码分离。
我只能想到两个解决方案：
1) 更新 web 应用程序以直接在 package.json 中使用传递依赖。然而，这破坏了“封装”，因为 Web 应用程序不应该知道直接依赖项如何管理其工作。如果直接依赖关系稍后要使用其他传递依赖关系，则不应让 Web 应用程序引用现在不相关的包。
2) 修改 web 应用程序的 package-lock.json 以指向新版本的传递依赖。然而，这似乎只是暂时起作用，因为合并冲突或直接依赖项的新安装往往会恢复这些更改。
我意识到答案可能是优化构建/发布过程以减少痛苦和手动，但我希望其他人可能会遇到不同的解决方案。
仅供参考 - 默认情况下，所有依赖项都以 '~' 作为版本前缀安装。