包管理规范

包命名规则

包名会成为模块url、命令行中的一个参数或者一个文件夹名称，任何非url安全的字符在包名中都不能使用
语义化包名，可以帮助开发者更快的找到需要的包
若包名称中存在一些符号，将符号去除后不得与现有包名重复, 例如：由于 react-native 已经存在，react.native、reactnative 都不可以再创建

版本管理：遵循 SemVer 规范

标准版本

标准版本号采用 X.Y.Z 的格式，其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素必须以数值来递增。

主版本号(major)：当你做了不兼容的修改
次版本号(minor)：当你做了向下兼容的功能性新增
修订号(patch)：当你做了向下兼容的问题修正

先行版本

当某个版本改动比较大、并非稳定而且可能无法满足预期的兼容性需求时，你可能要先发布一个先行版本，先行版本号可以加到 主版本号.次版本号.修订号 的后面，先加上一个中划线再加上一标识符和版本编译信息

内部版本(alpha)
公测版本(beta)
正式版本的候选版本(rc)

例如： react 截取的一部分版本号

'0.8.0',
'0.9.0-rc1',
'0.9.0',
'0.10.0-rc1',
'0.10.0',
'0.11.0-rc1',
'0.11.0',
'0.11.1',
'0.11.2',
'0.12.0-rc1',
'0.12.0',
'0.12.1',
'0.12.2',
'0.13.0-alpha.1',
'0.13.0-alpha.2',
'0.13.0-beta.1',
'0.13.0-beta.2',

注意，当主版本号为 0 的情况，会被认为是一个不稳定版本，情况与上面不同：

主版本号和次版本号都为 0 : ^0.0.z、~0.0.z 都被当作固定版本，安装依赖时均不会发生变化

主版本号为 0 : ^0.y.z 表现和 ~0.y.z 相同，只保持修订号为最新版本

1.0.0 的版本号用于界定正式发布。当你的软件发布到了正式环境，或者有稳定的 API 时，就可以发布 1.0.0 版本了

版本管理最佳实践

必须采用 X.Y.Z 的形式，其中 X, Y 和 Z 是非负整数，并且不得包含前导零
任何修改必须作为新版本发布
主版本 0 (0.y.z) 用于初始开发，建议从 0.1.0 开始发版
版本号 1.0.0 用于正式版发布
当次要版本增加时，补丁版本必须重置为 0 ，当主版本增加时，补丁和次要版本必须重置为 0

依赖管理

依赖包安装位置

dependencies 指定了项目运行所依赖的模块，开发环境和生产环境的依赖模块都可以配置到这里

{
    "lodash": "^4.17.13",
    "moment": "^2.24.0",
}

devDependencies, 有一些包有可能你只是在开发环境中用到，例如你用于检测代码规范的 eslint ，用于进行测试的 jest ，用户使用你的包时即使不安装这些依赖也可以正常运行，你可以把这些依赖添加到 devDependencies 中，这些依赖会在你本地进行 npm install 时被安装和管理，但是不会被安装到生产环境：

{
    "jest": "^24.3.1",
    "eslint": "^6.1.0",
}

peerDependencies 用于指定你正在开发的模块所依赖的版本以及用户安装的依赖包版本的兼容性，安装结束后检查本次安装是否正确，如果不正确会给用户打印警告提示。

{
    "react": ">=16.0.0",
    "react-dom": ">=16.0.0"
}

依赖包版本控制

“react”: “16.x”: 匹配主要版本（>=16.0.0 <17.0.0） - “react”: “16.3.x”: 匹配主要版本和次要版本（>=16.3.0 <16.4.0）
~: 当安装依赖时获取到有新版本时，安装到x.y.z 中z 的最新的版本。即保持主版本号、次版本号不变的情况下，保持修订号的最新版本
^: 当安装依赖时获取到有新版本时，安装到x.y.z 中y 和z 都为最新版本。即保持主版本号不变的情况下，保持次版本号、修订版本号为最新版本

本页目录

包命名规则版本管理：遵循 SemVer 规范

标准版本先行版本版本管理最佳实践

依赖管理

依赖包安装位置依赖包版本控制

包管理规范

包命名规则

版本管理：遵循 SemVer​​ ​规范

标准版本

先行版本

版本管理最佳实践

依赖管理

依赖包安装位置

依赖包版本控制

版本管理：遵循 SemVer 规范