>[success] # npm 查看一个包的版本信息
~~~
1.当想看npm 服务器上某个包的本时候
1.1.'npm view 查看的包名 versions' -- 这个会查到npm服务器上对应查询包的版本所有信息
1.2.'npm view 查看的包名 version' -- 这种方式只能查看的最新的版本是哪一个也就是tag为latest
1.3.'npm info 查看的包名' -- 也可以查看j所有的版本,但是能查出更多的关于查询包的信息;
2.'npm ls' -- 此命令将以树状结构将已安装软件包的所有版本及其依赖项打印到标准输出。
'npm ls -g' -- 全局安装依赖
3.'npm ls 查询包' 查看本地安装的查询的包版本,本地没有安装返回empty的结果;加'-g' 查询全局的
~~~
>[info] ## 版本
~~~
1.包的版本管理各种版本符号
version 精确匹配版本
>version 必须大于某个版本
>=version 大于等于
<version 小于
<=versionversion 小于
~version "约等于":
^version "兼容版本":
version1 - version2 相当于 >=version1 <=version2.
range1 || range2 范围1和范围2满足任意一个都行
~~~
>[danger] ##### 关于版本
1. **npm采用了semver规范作为依赖版本管理方案**。按照semver的约定,一个npm依赖包的版本格式一般为:'**主版本号.次版本号.修订号(x.y.z)**' -- 小提示 js有一个专门校验'semver' 库
1.1. '**主版本号(也叫大版本,major version)**':大版本的改动很可能是一次颠覆性的改动,也就意味着可能存在与低版本不兼容的API或者用法(比如 vue 2 -> 3)。**做了不兼容的 API 修改(可能不兼容之前的版本)**
1.2. '**次版本号(也叫小版本,minor version)**':小版本的改动应当兼容同一个大版本内的API和用法,因此应该让开发者无感。所以我们通常只说大版本号,很少会精确到小版本号。**做了向下兼容的功能性新增(新功能增加,但是兼容之前的版本)**
1.3. '**修订号(也叫补丁,patch)**':一般用于修复bug或者很细微的变更,也需要保持向前兼容,**做了向下兼容的问题修正(没有新功能,修复了之前版本的bug)**
1.4. '**先行版本**' 如下图vue3发行版本为例**当某个版本改动比较大、并非稳定而且可能无法满足预期的兼容性需求时,你可能要先发布一个先行版本**。**先行版本号**可以加到**主版本号.次版本号.修订号的后面**,先加上一个连接号再加上一连串以句点分隔的标识符和版本编译信息。'**内部版本(alpha)、公测版本(beta)、正式版本的候选版本rc: 即 Release candiate**'
* **alpha(α)**:预览版,或者叫内部测试版;一般不向外部发布,会有很多bug;一般只有测试人员使用。
* **beta(β)**:测试版,或者叫公开测试版;这个阶段的版本会一直加入新的功能;在alpha版之后推出。
* **rc(release candidate)**:最终测试版本;可能成为最终产品的候选版本,如果未出现问题则可发布成为正式版本。
* **总结**:semver作为包版本管理规范。此规范规定软件版本**由三个部分组成**:
* 主版本号做了不兼容的重大变更
* 次版本号做了向下兼容的功能添加
* 补丁版本号做了向下兼容的bug修复
* **注意**:
**如果大版本号是 0 的话,表示软件处于开发初始阶段**,一切都可能随时被改变,可能每个小版本之间也会存在不兼容性。所以在选择依赖时,**尽量避开大版本号是 0 的包**。
* vue3 版本发行
![](https://img.kancloud.cn/fa/d8/fad85f091ee09e533b335b76c24833c4_556x454.png)
>[danger] ##### 对于各个标志含义
~~~
1.~: 当安装依赖时获取到有新版本时,安装到 x.y.z 中 z 的最新的版本。即保持主版本
号、次版本号不变的情况下,保持修订号的最新版本。
2.^: 当安装依赖时获取到有新版本时,安装到 x.y.z 中 y 和 z 都为最新版本。 即保持主版
本号不变的情况下,保持次版本号、修订版本号为最新版本。
3.'*' 、"x" 或者 (空) 表示可以匹配任何版本。
注意: '当主版本号为 0 的情况,会被认为是一个不稳定版本'
主版本号和次版本号都为 0: ^0.0.z、~0.0.z 都被当作固定版本,安装依赖时均不
会发生变化。
主版本号为 0: ^0.y.z 表现和 ~0.y.z 相同,只保持修订号为最新版本。
~~~
>[danger] ##### 举几个例子
~~~
1."signale": "1.4.0": 固定版本号
2."figlet": "*": 任意版本(>=0.0.0)
3."react": "16.x": 匹配主要版本(>=16.0.0 <17.0.0)
4."react": "16.3.x": 匹配主要版本和次要版本(>=16.3.0 <16.4.0)
5."^xxx": 最左侧非0版本号不变,不小于xxx
^1.2.3 = >=1.2.3 <2.0.0 主版本号不变
^0.1.2 = >=0.1.2 <0.2.0 主、次版本号不变
^0.0.2 = = 0.0.2 主、次、补丁版本号都不变
6."~xxx":如果列出了次版本号,则次版本号不变,如果没有列出次版本号,则主版本号不
变,均不小于xxx
~1.2.3 = >=1.2.3 <1.3.0 主、次版本号不变
~1 = >=1.0.0 <2.0.0 主版本号不变
~~~
>[danger] ##### 预发布版本
~~~
1.以包开发者的角度来考虑这个问题:假设当前线上版本是 "1.2.3",如果我作了一些改动
需要发布版本 "1.2.4",但我不想直接上线(因为使用 "~1.2.3" 或者 "^1.2.3" 的用户都会
直接静默更新),这就需要使用预发布功能。因此我可能会发布 "1.2.4-alpha.1" 或者
"1.2.4-beta.1" 等等。
">1.2.4-alpha.1"表示接受 "1.2.4-alpha" 版本下所有大于 1 的预发布版本。因此 "1.2.4-alpha.7"
是符合要求的,但 "1.2.4-beta.1" 和 "1.2.5-alpha.2" 都不符合。此外如果是正式版本(不
带预发布关键词),只要版本号符合要求即可,不检查预发布版本号,例如 "1.2.5",
"1.3.0" 都是认可的。
"~1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 1.3.0"。这样 "1.2.5", "1.2.4-alpha.2" 都符合条
件,而 "1.2.5-alpha.1", "1.3.0" 不符合。
"^1.2.4-alpha.1" 表示 ">=1.2.4-alpha.1 < 2.0.0"。这样 "1.2.5", "1.2.4-alpha.2", "1.3.0"
符合条件,而 "1.2.5-alpha.1", "2.0.0" 不符合。
~~~
>[danger] ##### 小知识点
1. **1.0.0 的版本号用于界定公共 API**。当你的软件发布到了正式环境,或者有稳定的API时,就可以发布1.0.0版本了。所以,当你决定对外部发布一个正式版本的npm包时,把它的版本标为1.0.0。
>[danger] ##### 我想知道更多semver语义化
[semver语义化版本 2.0.0](https://semver.org/lang/zh-CN/)
- 工程化 -- Node
- vscode -- 插件
- vscode -- 代码片段
- 前端学会调试
- 谷歌浏览器调试技巧
- 权限验证
- 包管理工具 -- npm
- 常见的 npm ci 指令
- npm -- npm install安装包
- npm -- package.json
- npm -- 查看包版本信息
- npm - package-lock.json
- npm -- node_modules 层级
- npm -- 依赖包规则
- npm -- install 安装流程
- npx
- npm -- 发布自己的包
- 包管理工具 -- pnpm
- 模拟数据 -- Mock
- 页面渲染
- 渲染分析
- core.js && babel
- core.js -- 到底是什么
- 编译器那些术语
- 词法解析 -- tokenize
- 语法解析 -- ast
- 遍历节点 -- traverser
- 转换阶段、生成阶段略
- babel
- babel -- 初步上手之了解
- babel -- 初步上手之各种配置(preset-env)
- babel -- 初步上手之各种配置@babel/helpers
- babel -- 初步上手之各种配置@babel/runtime
- babel -- 初步上手之各种配置@babel/plugin-transform-runtime
- babel -- 初步上手之各种配置(babel-polyfills )(未来)
- babel -- 初步上手之各种配置 polyfill-service
- babel -- 初步上手之各种配置(@babel/polyfill )(过去式)
- babel -- 总结
- 各种工具
- 前端 -- 工程化
- 了解 -- Yeoman
- 使用 -- Yeoman
- 了解 -- Plop
- node cli -- 开发自己的脚手架工具
- 自动化构建工具
- Gulp
- 模块化打包工具为什么出现
- 模块化打包工具(新) -- webpack
- 简单使用 -- webpack
- 了解配置 -- webpack.config.js
- webpack -- loader 浅解
- loader -- 配置css模块解析
- loader -- 图片和字体(4.x)
- loader -- 图片和字体(5.x)
- loader -- 图片优化loader
- loader -- 配置解析js/ts
- webpack -- plugins 浅解
- eslit
- plugins -- CleanWebpackPlugin(4.x)
- plugins -- CleanWebpackPlugin(5.x)
- plugin -- HtmlWebpackPlugin
- plugin -- DefinePlugin 注入全局成员
- webapck -- 模块解析配置
- webpack -- 文件指纹了解
- webpack -- 开发环境运行构建
- webpack -- 项目环境划分
- 模块化打包工具 -- webpack
- webpack -- 打包文件是个啥
- webpack -- 基础配置项用法
- webpack4.x系列学习
- webpack -- 常见loader加载器
- webpack -- 移动端px转rem处理
- 开发一个自己loader
- webpack -- plugin插件
- webpack -- 文件指纹
- webpack -- 压缩css和html构建
- webpack -- 清里构建包
- webpack -- 复制静态文件
- webpack -- 自定义插件
- wepack -- 关于静态资源内联
- webpack -- source map 对照包
- webpack -- 环境划分构建
- webpack -- 项目构建控制台输出
- webpack -- 项目分析
- webpack -- 编译提速优护体积
- 提速 -- 编译阶段
- webpack -- 项目优化
- webpack -- DefinePlugin 注入全局成员
- webpack -- 代码分割
- webpack -- 页面资源提取
- webpack -- import按需引入
- webpack -- 摇树
- webpack -- 多页面打包
- webpack -- eslint
- webpack -- srr打包后续看
- webpack -- 构建一个自己的配置后续看
- webpack -- 打包组件和基础库
- webpack -- 源码
- webpack -- 启动都做了什么
- webpack -- cli做了什么
- webpack - 5
- 模块化打包工具 -- Rollup
- 工程化搭建代码规范
- 规范化标准--Eslint
- eslint -- 扩展配置
- eslint -- 指令
- eslint -- vscode
- eslint -- 原理
- Prettier -- 格式化代码工具
- EditorConfig -- 编辑器编码风格
- 检查提交代码是否符合检查配置
- 整体流程总结
- 微前端
- single-spa
- 简单上手 -- single-spa
- 快速理解systemjs
- single-sap 不使用systemjs
- monorepo -- 工程
- Vue -- 响应式了解
- Vue2.x -- 源码分析
- 发布订阅和观察者模式
- 简单 -- 了解响应式模型(一)
- 简单 -- 了解响应式模型(二)
- 简单 --了解虚拟DOM(一)
- 简单 --了解虚拟DOM(二)
- 简单 --了解diff算法
- 简单 --了解nextick
- Snabbdom -- 理解虚拟dom和diff算法
- Snabbdom -- h函数
- Snabbdom - Vnode 函数
- Snabbdom -- init 函数
- Snabbdom -- patch 函数
- 手写 -- 虚拟dom渲染
- Vue -- minVue
- vue3.x -- 源码分析
- 分析 -- reactivity
- 好文
- grpc -- 浏览器使用gRPC
- grcp-web -- 案例
- 待续