如何设计npm包的开发和发布流程

最近在把公司内部用的一个库发布到内网的npm私服上，仅仅是发布的话是比较简单的，但这个库是由多个人一起维护的，而且npm私服只有一套，所以生产环境和开发环境，用的是同一个，那么，我们的需求来了：如何设计npm包的开发流程和自动化发布流程。 这一套流程我们想要的达成如下目标

1. 支持团队协作，有开发提交代码，其他人能及时同步到最新代码
2. 能够支持常规迭代和hotfix上线
3. 同一版本开发、测试、生产环境的引用包的版本号都是一致的
4. 自动化发布，减少人工操作

先说下如何搭建npm私服和如何发包，不过这不是我们这篇要讲的重点，所以我们就简单介绍

npm私服搭建

目前比较主流的有 nexus 和 Verdaccio，因为 Verdaccio 要更轻量些，而且也满足我们的需求，所以我们选择它。 Verdaccio 搭建非常简单，直接使用默认配置就行

npm install -g verdaccio
or
yarn global add verdaccio
verdaccio

就这样，私服就搭建完成啦。

npm包发布

有了私服，我们先注册到本地的npm中
npm set registry http://localhost:4873
然后添加用户，如果是首次，则会新建用户
npm adduser --registry http://localhost:4873
最后是发布
npm publish

设定版本号有两种方式，一种是人工修改 package.json 中的 version

// package.json
{
   
  "name": "project",
  "version": "1.0.0",
}

另一种是通过 npm version 来修改版本号，提供有这如下参数

npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]

详细解释如下：

newversion：自定义版本号，除了已经发布的版本号，想写啥写啥
major：升级主版本号 1.0.0 -> 2.0.0
minor：升级次版本号 1.0.0 -> 1.1.0
patch：升级补丁号 1.0.0 -> 1.0.1  
premajor：预备主版本
preminor：预备次版本
prerelease：预发布版本

在执行npm version后，会产生一条新的提交记录，比如说执行 npm version 2.0.0完后 ，查看log，会发现一条 commit message 为 2.0.0 的提交记录，至于为啥会生成这条记录呢？很简单，因为npm version这行命令其实是修改了 package.json 中的 version ，修改后并提交，所以就有这条新的提交记录。要是想自定义提交记录，可以这么写 npm version 2.0.0 -m "Upgrade to %s for reasons" 其中%s就是修改后的版本号。

gitlab CI

我们打算使用 gitlab CI 来实现自动化发布，我们也简单介绍下 gitlab CI 的一些步骤和配置项。

1. 项目开启CI，选择一个公共的 runner，要是没有，那就只能自己弄一个。
2. 项目根目录新建 .gitlab-ci.yml，写入配置，详细的配置可以查看 gtilab官网

# 定义 stages
stages:
  - build

定义 job