一篇解决npm私有包开发调试频繁的文章初始版本号快速增长导致：版本号过多，版本号转移过程繁琐，组件库重复安装之痛。本文将重点解决这三个问题。一、问题npm包版本号的快速增长带来了以下问题：调试变得不方便。之前真机测试只需要发布测试环境，现在需要先发布npm包，安装npm包，再发布测试环境，由一步变成了三步。联调难度大的版本号快速更新，导致每次都要通知相关同学新的版本号。这个过程中也容易出现错误，导致安装错误的版本或者没有及时更新。增加了应试同学的负担。丑包版本号一个小功能就推出了几十个版本，从1.0.0到1.0.3X，挑战的不仅是自己的容忍度，还有小伙伴的安全感。2.解决方案1.1调试时使用npmlinknpmlink可以在项目和要使用的npm包之间建立符号链接。也就是说，如果在项目A中使用组件包B，之前需要打包发布B，然后在项目A中安装B，打包发布测试环境进行验证，现在只需要打包B，和A直接打包发布测试环境就可以了（A打包的时候拿到B的本地打包文件，也就是B的package.json里面写的主文件）PS：如果用yarn，还有yarn链接，和yarnlink不会污染全球环境。使用npmlink需要做如下步骤：B包中：npmlink//等同于npminstallB-gA包中：npmlinkB//代码不用修改，引用B在package.json包会自动指向本地B的包文件。一个包发布测试环境test使用npmlink方式。所有小的调整都可以在不发送包的情况下进行验证，特别是对于无法正确确定的测试更改。.需要注意的是，去掉npm包的版本控制后，代码的版本控制一定要在git上做，否则可能会丢失代码。1.2发布时，使用tagtag表示版本号。用户可以使用npminstall@来安装。对于大多数用户，使用npminstall安装所有依赖项。在这种情况下，系统会自动安装最新版本号。需要注意的是，我们会经常发布测试版本。如果此时用户安装，会拉出一个有问题的测试版，所以我们需要使用标签来区分版本。另外，在联调阶段，反复告知对方我们的版本号从1.3.1变成了1.3.x是很愚蠢的，所以我们可以指定一个tag来维护版本转移。同时在B包中使用npminfo观察各个标签的版本号。npmpublish--tag使用latest设置用户npminstall的默认安装版本，使用alpha设置测试版本，测试测试版本时，使用npmdist-tagadd@[]切换不同标签的版本号。比如1.3.1已经测试过了。我们可以使用npmdist-tagaddB@1.3.1latest将原来属于alpha的分支切换到latest。如果不加tag，默认是latest。当然你也可以通过mpmdist-tagadd添加自己的tag。2.相关知识2.1package.json和package-lock.jsonpackage.json：用于标记项目中各个npm包的依赖关系。package-lock.json：用于记录当前状态下实际安装的每个npm包的具体来源和版本号。由于package.json中默认的是@tencent/newsH5Ad:'^1.3.1'，^指的是向后兼容，这就导致安装npmi的时候，安装的库版本和之前的不一样（可能版本号会更新），而这时候，如果npm包开发者不遵守——“相同大版本号的包，接口保持兼容”——是的，我说的——兼容性问题就会发生。为了解决这个问题，就有了package-lock.json。在不同版本的npm下，package-lock.json有不同的表现。最新版本是npm5.4.2以后：如果package.json发生变化，package.json和lock文件不同，那么执行npmi时，npm会下载最新的包，根据版本号和语义进行更新包中的意思是锁定。如果两者状态相同，则执行npmi会根据锁进行下载，而不管包的实际包版本是否是新的。[1]说到这里，package-lock.json是yarn.lock的一个实现。事实上，应该使用纱线。使用npmi真是自找麻烦。。。2.2版本号前几个字不好说。记住~version:大概是某个版本~1.2.1is>=1.2.1&&<1.3.0^version:backwardcompatible^1.2.1is>=1.2.1&&<2.0.0versionnumberformat:mainversionNo.次要版本号。补丁版本号主版本号：新增功能，兼容旧版本次版本号：Bug修复，兼容旧版本补丁版本号：新架构调整，不兼容旧版本，详见《package.json中 npm依赖包版本前的符号的意义》3。总结通过npmlink和tag，我们可以尽可能减少库包的调试步骤和发布，从而形成良好的库包管理。
