使用 NPM 将包更新到主要版本 [英] Update package to a major release with NPM

问题描述

在 Node.js 项目中，我不清楚升级包的正确工作流程是什么到一个主要版本.

假设我正在安装 stylelint:npm install --save stylelint 默认在我的 package.json 中放入字符串 "stylelint": "^8.4.1" 这意味着如果我想用 npm update 更新它，我只会得到小版本和补丁版本(8.4.2 可以，8.5.0 可以，9.0.0 不是).

如果我检查 npm outdated 并发现我可以更新到 9.0.0，由于上述限制，npm update 将无法工作.

那么，如果我想升级，我该怎么做?

我是否需要手动修改我的 package.json 到 stylelint 版本 ^9.0.0，删除 node_modules 目录并重新运行 npm install?

或者我可能只需要删除 ^ 字符来让 npm update 完成它的工作?

要采用的通用/最佳实践是什么?

谢谢

解决方案

或者我可能只需要删除 ^ 字符就可以让 npm update 完成它的工作?

<块引用>

要采用的通用/最佳实践是什么?

最常见/最佳的做法是永远不允许自动更新具有潜在破坏性更改的版本.工作流程遍布地图，从；手动测试然后更新packages.json，实现packages.json的全自动检测、测试、更新和提交.

由于缺乏并行版本控制支持，许多 Java/JavaScript 环境对传递依赖项更改特别敏感.如果您的包对其自身的依赖项之一进行了重大更改，那么您的包已对系统进行了重大更改.如果您的 1.y.z 导致其依赖项之一从 X.Y.Z 更新到 X+1.Y.Z，则它会引入一个重大更改，因此不是稳定的 1.y.z 版本.其他依赖于与您的包名称相同的包名称的包可能会在该包的开发人员发布破坏性更改时被破坏.永远不要让世界进入那种状态！

我建议您研究 钻石依赖问题 并牢记在心.您应该始终仔细测试重大更改，切勿尝试将它们强加给您的客户.

正如@ShaharShokrani 所指出的，这个答案 为手动更新包提供了一个很好的工作流程.并保持符合 SemVer 2.0.0 #8，不要忘记碰撞您自己的主要版本号.

Inside a Node.js project, it's not clear to me what is the correct workflow to ugpgrade a package to a major release.

Let's suppose I'm istalling stylelint: npm install --save stylelint by default puts inside my package.json the string "stylelint": "^8.4.1" which means that if I want to update it with npm update, I will get only minor and patch releases (8.4.2 is ok, 8.5.0 in ok, 9.0.0 is not).

If I check with npm outdated and it comes out that I could update to 9.0.0, npm update wouldn't work because of the restriction depicted above.

So, if I want to upgrade, what am I supposed to do?

Have I to manually modify my package.json to stylelint version ^9.0.0, delete node_modules directory and re-run npm install?

Or maybe I have just to remove the ^ character to let npm update do its job?

What is the common/best practice to adopt?

Thanks

解决方案

Or maybe I have just to remove the ^ character to let npm update do its job?

What is the common/best practice to adopt?

The most common/best practice is to never allow automatic updates to versions that have potentially breaking changes. Workflows are all over the map, from; manual test and then update packages.json, to fully automated detect, test, update and submission of packages.json.

Many Java/JavaScript environments are particularly sensitive to transitive dependency changes due to the lack of side by side versioning support. If your package brings in a breaking change of one of its own dependencies, then your package has introduced a breaking change to the system. If your 1.y.z causes an update of one of its dependencies from X.Y.Z to X+1.Y.Z it introduces a breaking change and is therefore not a stable version 1.y.z. Other packages that depend on the same package name as yours could potentially be broken whenever the developers of that package released a breaking change. Never let the world get into that state!

I recommend you study the Diamond Dependency Problem and take to heart. You should always carefully test breaking changes and never try to force them on your customers.

As pointed out by @ShaharShokrani, this answer gives a good workflow for manually updating your package. And to remain in compliance with SemVer 2.0.0 #8, don't forget to bump your own major version number.

这篇关于使用 NPM 将包更新到主要版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！