npm发包一定要了解的知识

1. registry

在下载包的时候，很多人喜欢设置taobao镜像，因为npm仓库服务器在国外，下载速度真是急死个人。发布的时候也一样，一般开源应用基本都发布到npmjs，公司内部包的话就会发到私有Npm仓库，我们可以在package.json设置一下你想要的发布的地址：

"publishConfig": {
    "registry": "http://registry.npm.xxx.com/"
 }

也可以设置别名

alias ynpm="npm --registry=http://registry.npm.xxx.com"
// 发布的时候
ynpm publish

2. 发布哪些文件（两种方式）？

发布一个包，考虑到别人的下载速度，包体积肯定需要尽量小，所以源文件最好不包括，那如何控制只发哪些文件呢？

第一种方式是在 package.json 里 files 字段来控制，这个字段中的文件默认会加入到npm publish 发布的包中，它的优先级高于.npmignore和.gitignore。files 字段的值是一个数组，你可以写具体文件名，也可以写目录，还支持 glob 模式。

第二种就是使用 .npmignore 配置文件，在.npmignore中的文件不会被发布。他类似于 .gitignore ，其实如果没有 .npmignore，会使用.gitignore来取代他的功能。如果同时存在，那么.npmignore的优先级更好。在包的根目录下，.npmignore不会覆盖 files 字段，但在子目录中会覆盖。

有些文件无法通过配置排除或者包含：

• package.json
• README
• CHANGES / CHANGELOG / HISTORY
• LICENSE / LICENCE
• NOTICE
• main字段中的文件

以上文件是默认发布的，无法忽略。所以当你npm publish的时候，为啥总会有package.json文件，明白了吧？这几个文件在npm publish的时候都是默认作为包的一部分的。

• .git
• CVS
• .svn
• .DS_Store
• ._*
• 等等

以上文件无法发布到 npm。

3. 版本管理

npm的发包需要遵循语义化版本，一个版本号包含三个部分：MAJOR.MINOR.PATCH，

• MAJOR 表示主版本号，当你做了不兼容的API修改；
• MINOR 表示次版本号，当你做了向下兼容的功能性新增；
• PATCH 表示修订号,当你做了向下兼容的问题修正;

我们可以使用npm version 命令来自动修改版本号，比如：

// version = v1.0.0
npm version patch
// v1.0.1
npm version prepatch
// v1.0.2-0
npm version minor
// v1.1.0
npm version major
// v2.0.0

一般来说还有先行版本，测试版本等，他们这样命名

• 3.1.0-beta.0
• 3.1.0-alpha.0

如果我们发布先行版本，npm version prepatch 命令得出的版本号好像就不够规范了，我们只能使用 npm version 1.0.0-alpha.1 指定版本号，不过还好，在 npm 6.4.0 之后，我们可以使用 --preid 参数：

npm version prerelease --preid=alpha

4. Changelog

包发布了很多次后，使用者升级就需要知道他是否需要升级，需要查看文档看看有哪些不兼容性改动，所以需要一个 Changelog 来记录每次发布改了些什么。如果手动的维护肯定会有忘记的时候，所以需要使用工具来自动生成，我们可以使用standard-version 这个包来生成，这个包的作用是自动更新版本和生成CHANGELOG。

有了这个工具我们都不需要使用npm version prepatch了。standard-version会根据你的git commit信息，自动生成日志，比如新增啥啥功能，修复啥啥啥bug。自动生成的同时，也就意味着你git commit需要遵循一定格式，比如：

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-co lons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance

我们可以使用 commitlint搭配 husky 来校验你commit的信息是否符合标准

{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }  
  }
}

也可以使用交互式的方式来生成commit，commitizen这个包就可以。

5. 模块 tag 管理

不经常发布包的同学可能对模块 tag 概念不是很清楚。以vue为例，首先执行npm dist-tag ls vue查看vue包的tag：

beta: 2.6.0-beta.3
csp: 1.0.28-csp
latest: 2.6.10

上面列出的beta、csp、latest就是tag。每个tag对应了一个版本。

一般来说我们至少会有三种类型的标签

• latest：最后版本，npm install的就是这个
• beta：测试版本，一般内测使用，需要指定版本号install，例如3.1.0-beta.0
• next: 先行版本，npm install foo@next安装，例如3.0.2-alpha.0

那tag到底有什么用呢？tag类似于git里面分支的概念，发布者可以在指定的tag上发布版本，而使用者可以选择指定的tag来安装包。不同的标签下的版本之间互不影响，这在发布者发布预发布版本包和使用者尝鲜预发布版本包的同时，不影响到正式版本。

在发布包的时候执行npm publish默认会打上latest这个tag，实际上是执行了npm publish --tag latest。而在安装包的时候执行npm install xxx则会默认下载latest这个tag下面的最新版本，实际上是执行了npm install xxx@latest。当然，我们也可以自定义tag：

# 当前版本为1.0.1
npm version prerelease  # 1.0.2-0
npm publish --tag beta  # 发布一个测试版本
npm dist-tag ls xxx  # # beta: 1.0.2-0
npm install xxx@beta  # 下载beta版本 1.0.2-0

当prerelease版本已经稳定了，可以将prerelease版本设置为稳定版本：

npm dist-tag add xxx@1.0.2-0 latest
npm dist-tag ls xxx  # latest: 1.0.2-0

如果你直接执行npm publish，那么即使你的版本号是-beta.n，默认会打上latest的标签，别人install的时候也会下载到。这个时候需要我们只要改一下tag：

// 不小心发错了
latest: 1.0.1-beta.0
// 将1.0.1-beta.0设置为beta
npm dist-tag add my-package@1.0.1-beta.0 beta
npm dist-tag add my-package@1.0.0 latest