前言
在日常工作中,当组件跨项目使用时,我们往往会选择把组件抽成 npm 包。那么在 npm 开发以及发布的过程中有什么需要注意的事项吗?本文将从我自己的角度,来为大家介绍一下我认为的一些需要大家注意的点。
版本号规则
从日常的开发中我们可以看到,npm 包的版本号的格式都是 X.Y.Z。蓝狮注册登陆那么大家发布的 npm 包为什么都在遵循这个格式呢?这个格式其实是由 Gravatars 创办者兼 GitHub 共同创办者 [Tom Preston-Werner] http://tom.preston-werner.com/ 所建立。由 GitHub 起草的统一的版本号表示规则,称为 Semantic Versioning (语义化版本表示)。这些规范具体包含的内容大家可以参考[语义化版本 2.0.0] https://semver.org/lang/zh-CN/ 本文只针对我们开发中容易忽略的地方做一些详述。
X 代表主版本号,也叫做大版本号
升级大版本时意味着这个包可能做了颠覆性的改动,和低版本的包已经 无法兼容 。每当主版本号递增时,次版本号和修订号必须归零。
Y 代表次版本号,也叫做小版本号
当做了 向下兼容 的功能性新增时,升级小版本号。每当次版本号递增时,修订号必须归零。
Z 代表修订号
当做了 向下兼容 的问题修正(bugfix)时, 升级修订号。
常见版本格式/引用方式
版本引用方式 版本号 匹配版本 解释
直接使用版本号 2.3.1 2.3.1 只可以匹配 2.3.1 这个版本,如果是比较重要的项目,建议用这种方式固定版本。
^:不能修改版本号最左侧非零数字 ^2.3.1 >= 2.3.1 && < 3.0.0 最左侧非零数字是 2 ^0.3.1 >= 0.3.1 && < 0.4.0 最左侧非零数字是 3 ^0.0.1 >= 0.01 && < 0.02,即 0.01 最左侧非零数字是 1 ~:版本号列出 Y 时兼容 Z 的修改。列出 X 时兼容 Y、Z ~2.3.1 >= 2.3.1 && < 2.4.0 Y 为 3。~2.3 同理 ~2 >= 2.0.0 && < 3.0.0 X 为 2 、X、x,空:表示可以匹配任何版本 “2.3.X”、”2.3.x”、”2.3“、”2.3” >= 2.3.0 && < 2.4.0 Z 可以为任意值 “2.X”、”2.x”、”2.*”、”2” >= 2.0.0 && < 3.0.0 Y、Z 为任意值
*、X、x,空 任意版本 任意版本指的是最新的正式版
关于 npm 的版本格式还有许多,此处不再赘述。
从上边的常用格式介绍可以看出来,在精确版本号的情况下,版本号是完全固定的,在项目发布时不会出现一些实际安装的包和 package.json 中版本号不一致的问题。或者如果使用方有用到 package-lock.json 文件来固定包的版本,也可以避免包的版本号导致的问题。
但是在实际开发中,蓝狮官网我们并不知道我们包的使用方是否使用的固定版本号或者 package-lock.json 文件,我们怎么做才能让使用方不受影响呢?
这时候就要用到先行版本号了,下面我将为大家具体介绍。
先行版本
npm 的先行版本号,放到 X.Y.Z 的后边,作为延伸。被标上先行版本号则表示这个版本 并非稳定 而且 可能无法满足预期 的兼容性需求。例如:1.0.0-alpha.1,2.0.0-beta.1 等。一般常用的关键词有:
alpha:预览版,或者叫内部测试版;一般不向外部发布,会有很多 bug(会不太稳定);一般只有测试人员使用。
beta:测试版,或者叫公开测试版;这个阶段的版本会一直加入新的功能;在 alpha 版之后推出。
rc(release candidate):最终测试版本;可能成为最终产品的候选版本,如果未出现问题则可发布成为正式版本。
先行版本升级规则
我们使用 npm dist-tag ls @zcy/zcy-region-detail-back 查看 @zcy/zcy-region-detail-back 的 tag,如下:
我们可以看到这个包有一个 beta 版,一个 latest 版。
对比两个版本的名字可以发现,beta 版本是在 latest 版本的 Z 上加了 1 且添加了一个 beta 作为延伸。
如果包只是对现有的问题进行修复,那么只需要对 Z 进行加 1,然后添加延伸。
如果包本次是做 向下兼容 的功能性新增,那么需要对 Y 进行加 1,Z 清零,然后添加延伸。
如果包本次的升级是 无法向下兼容 的,那么就需要对 X 进行加 1,Y、Z 清零,然后添加延伸。
如果在加了延伸的版本上需要进行 bugfix 时,只需要将我们延伸的版本继续增加即可。当 bugfix 结束,需要发布正式版本时,只需要去掉延伸版本,发布版本即可。
0 Comments