维护和更新大型私人NPM软件包生态系统的最佳实践
在大型内部生态系统中维护和保持最新的NPM软件包的最简单/最佳方法是什么？
假设我们有许多不同的私人NPM软件包，每个软件包都有自己的存储库，它们以树状的方式消费。请注意，该图是用于讨论目的的问题的非常简单的版本。实际的依赖树很容易10倍。 如果您需要更改低级软件包，那么更新树的其余部分的最佳/最简单方法是什么？
- 我们的前端网站。
- 中层蓝色框代表中间软件包 由顶级网站消费，也消耗其他低级 软件包。
- 低级橙色盒子代表包装的包裹 由其他软件包和网站消费。
示例：将更改更改为低级软件包，
我们假设所有这些软件包目前都在v1.0.0上，以此为目的。要更新 @adc/package-1，必须：
- 在 @adc/package-1中进行更改，然后发布新版本（v2.0.0）
- 更新中级软件包以消耗 @adc/package-1 @^2.0。 0。
- 发布中级软件包的新版本（即 @adc/， @adc/ 保护” class =“ __ cf_email__” data-cfemail =“ 1969787A72787E7C342D592837293728”>
- href =“/cdn-cgi/l/电子邮件 软件包。
这总共需要六个PR，因为每个软件包都是其自己的存储库。这些更新中的大多数只是更新版本号。它还要求PRS按特定顺序合并。这是一个简单更改的开销，与可能存在的实际软件包生态系统相比，这又是非常简化的。
如果我们不更新中级软件包，会发生什么？
顶级网站现在将使用两个不同版本的 @adc/package-1。
- @adc/package-1@^2.0.0通过其package.json direct dectionency
- @adc/package-1@^1.0.0通过瞬态依赖性通过中级软件包。
我相信这可能导致非确定性行为，这也使下一个开发人员很难知道如果需要进行更新，他们应该/应该使用哪些版本。中层软件包将变得过时，最终将需要我们将所有 @ADC/软件包版本更新为最新版本。在您试图减轻风险的世界中，这意味着回归测试整个软件包和所有消费包/网站。
What is the easiest/best way to maintain and keep up-to-date NPM packages in a large, internal ecosystem?
Say we have a number of different private NPM packages, each a project with its own repository, that are consumed in a tree-like fashion. Note that this diagram is a very simplified version of the problem for discussion purposes. The actual dependency tree is easily 10x this complex. If you need to make a change to a low-level package, what is the best/easiest way to update the rest of the tree?
- The top-level green boxes represent our front-end websites.
- The mid-level blue boxes represent intermediate packages which are
consumed by the top-level websites, and also consume other low-level
packages. - The low-level orange boxes represent packages which get
consumed by other packages and websites.
Example: Breaking Change to a Low-Level Package
We'll assume all of these packages are currently on v1.0.0 for the sake of this example. To update @adc/package-1, one must:
- Make the changes in @adc/package-1 and publish the new version (v2.0.0)
- Update the mid-level packages to consume @adc/package-1@^2.0.0.
- Publish new versions of the mid-level packages (i.e. @adc/[email protected], @adc/[email protected], @adc/[email protected])
- Update the top-level websites to consume all new versions of the packages.
This in total requires six PRs, since each package is its own repository. Most of these updates are just updating the version numbers. It also requires that the PRs are merged in a particular order. This is a lot of overhead for a simple change, and again this is very simplified in comparison to the actual package ecosystem that may exist.
What happens if we don't update the mid-level packages?
The top-level websites will now be using two different versions of @adc/package-1.
- @adc/package-1@^2.0.0 via its package.json direct dependency
- @adc/package-1@^1.0.0 via a transient dependency through the mid-level packages.
I believe this can lead to non-deterministic behavior, and it also makes it difficult for the next developer to know what versions they can/should use if they need to make an update. The mid-level packages would become out-of-date and eventually it would require us to update all @adc/ package versions to the latest. In a world where you try to mitigate risk, this would mean regression testing the entire package and all consuming packages/websites.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们已经将内部NPM软件包迁移到monorepo中，并使用 pnpm ，更改和 nx 。
我相信MonorePo会带来自己的挑战，但是目前，这种节拍有大量的个人拉力请求，每个旧存储库都一个。
We have migrated our internal NPM packages into a monorepo and utilized PNPM, Changesets, and NX.
I am sure the monorepo will come with its own challenges, but currently this beats having a multitude of individual pull requests, one for each of the old repositories.