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