💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
>[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/)