语义版本
版本规范:主版本号.次版本号.补丁版本号
- 主版本号:仅当程序发生了重大变化时才会增长,如新增了重要功能、新增了大量的API、技术架构发生了重大变化
- 次版本号:仅当程序发生了一些小变化时才会增长,如新增了一些小功能、新增了一些辅助型的API
- 补丁版本号:仅当解决了一些 bug 或 进行了一些局部优化时更新,如修复了某个函数的 bug、提升了某个函数的运行效率
常见语义版本的书写方式
符号 | 描述 | 示例 | 示例描述 |
---|---|---|---|
> | 大于某个版本 | >1.2.1 | 大于1.2.1版本 |
>= | 大于等于某个版本 | >=1.2.1 | 大于等于1.2.1版本 |
< | 小于某个版本 | <1.2.1 | 小于1.2.1版本 |
<= | 小于等于某个版本 | <=1.2.1 | 小于等于1.2.1版本 |
- | 介于两个版本之间 | 1.2.1 - 1.4.5 | 介于1.2.1和1.4.5之间 |
x | 不固定的版本号 | 1.3.x | 只要保证主版本号是1,次版本号是3即可 |
~ | 补丁版本号可增 | ~1.3.4 | 保证主版本号是1,次版本号是3,补丁版本号大于等于4 |
^ | 此版本和补丁版本可增 | ^1.3.4 | 保证主版本号是1,次版本号可以大于等于3,补丁版本号可以大于等于4 |
* | 最新版本 | * | 始终安装最新版本 |
避免还原的差异(package-lock.json)
版本依赖控制始终是一个两难的问题
如果允许版本增加,可以让依赖包的bug得以修复(补丁版本号),可以带来一些意外的惊喜(次版本号),但同样可能带来不确定的风险(新的bug)
如果不允许版本增加,可以获得最好的稳定性,但失去了依赖包自我优化的能力
而有的时候情况更加复杂,如果依赖包升级后,依赖也发生了变化,会有更多不确定的情况出现
基于此,npm 在安装包的时候,会自动生成一个 package-lock.json 文件,该文件记录了安装包时的确切依赖关系
当移植工程时,如果移植了 package-lock.json 文件,恢复安装时,会按照 package-lock.json 文件中的确切依赖进行安装,最大限度的避免了差异
npm的差异版本处理
如果两个包依赖同一个包的不同版本,如下图
A —> C 1.4.0
B —> C 1.2.3
面对这种情况,在 node_modules 目录中,不会使用扁平的目录结构,而会形成嵌套的目录,如下图:
├── node_modules
│ ├── a
│ │ ├── node_modules
│ │ │ ├── c
│ │ │ | |—— c包的文件
│ │ │── a包的文件
│ ├── b
│ │ ├── node_modules
│ │ │ ├── c
│ │ │ | |—— c包的文件
│ │ │── b包的文件
常用npm命令
安装
- 精确安装最新版本
npm install --save-exact 包名
npm install -E 包名
- 安装指定版本
npm install 包名@版本号
查询
- 查询包安装路径
npm root [-g]
- 查看包信息
npm view 包名 [子信息]
## view aliases:v info show
- 查询安装包
npm list [-g] [--depth=依赖深度]
## list aliases: ls la ll
- 查看仓库地址
npm config get registry
- 设置淘宝镜像源
npm config set registry https://registry.npm.taobao.org
更新
- 检查有哪些包需要更新
npm outdated
- 更新包
npm update [-g] [包名]
## update 别名(aliases):up、upgrade
卸载包
npm uninstall [-g] 包名
## uninstall aliases: remove, rm, r, un, unlink
发布包
准备工作
- 移除淘宝镜像源
- 到npm官网注册一个账号,并完成邮箱认证
- 本地使用 npm cli 进行登录
- 使用命令
npm login
登录 - 使用命令
npm whoami
查看当前登录的账号 - 使用命令
npm logout
注销
- 使用命令
- 创建工程根目录
- 使用npm init进行初始化
发布
- 开发
- 确定版本
- 使用命令
npm publish
完成发布
开源协议
可以通过网站 http://choosealicense.online/appendix/ 选择协议,并复制协议内容