前言

在内部组织架构开发npm包时，很多人会想到规范问题，难道按前文gitlab结合semantic-release自动化规范git流程(一)所描述根据git的CI/CD就可以了吗，每次发布都会版本对应的新增，而往往新增的版本不是我们所需要的，我们可能最起码的还需要进行单元测试、内部的功能测试、再到公测…才能作为一个稳定的版本去使用。那么具体该怎么做呢，今天就来讲述一下内部该怎么规范和执行一个npm发布？

一、开发流程

在内部开发时，可以以gitlab为参考标准，大体流程与开源流程接近，唯一的区别即开发者可以直接在其他分支进行开发，无需拉取额外的PR。

   1.1 技术需求评审/优化功能评审，插件设计的功能点是否有必要进行，功能点的markdown文档（属性、事件、案例），哪些核心功能点的单元测试 - 对标github的讨论区

   1.2 确定之后通知 上级  建立git，根据项目特性，创建完整的git CI工作流

   1.3 插件/组件核心功能要有合理的单元测试，比如通常保证script有test的命令可执行（npm run test）

   1.4 功能feat分支开发完毕，申请合并至alpha分支，人工review代码设计是否合理，单元测试是否合理达标

   1.5 确定完毕，同意合并至alpha分支并触发单元检测job，单元测试通过后会触发job2:自动化发布至alpha内测版

   1.6 内测版经过测试没有问题，将合并至beta分支，触发job2，自动化发布至beta版，进行公测

   1.7 公测无问题，将合并至master分支，触发job2，自动化发布至正式稳定版

二、npm命名规范

如果是单一的插件，或者组件库可直接小写英文以横岗进行拼接（如：element-ui）,如果是关联性比较强的，类属于一个项目分类的子包，要以 @项目名称/子包名称的形式（如：@ests-sdk/wx、@ests-sdk/baidu）

三、 git CI/CD的流程

主分支流程： alpha-beta-master（alpha、beta、master均设置为保护分支，非管理员不可提交）

四、git CI/CD触发机制

添加gitlab.yml文件控制git自动化ci工作流，达到发布的目的。在对应分支会触发job1:单元检测、和job2：执行自动构建发布流，固定的commit提交格式才会触发job中的自动化发布（版本控制、tag、changelog等）。

五、git commit提交规范

提交一个bug修复，如git commit -m ‘fix: 修复了xxx’ 或者 git commit -m ‘fix(某个功能备注): 修复了xxx’
feat 功能feature的意思，也是最常用的。当你的功能有变更的时候，都可以采用这种类型的type ,版本变化v1.0.0—>v1.1.0

- fix当然指的是bug修复 版本变化v1.0.0--->v1.0.1 	
- docs 更新了文档，或者更新了注释 	
- style代码格式调整，比如执行了format、更改了tab显示等  版本变化v1.0.0--->v1.0.1 	
- refactor 重构代码。指的是代码结构的调整，比如使用了一些设计模式重新组织了代码 版本变v1.0.0--->v1.0.1
- perf对项目或者模块进行了性能优化。比如一些jvm的参数改动，把string buffer改为string builder等 版本变化v1.0.0--->v1.0.1 
- test 这个简单，就是增加了单元测试和自动化相关的代码
- build 影响编译的一些更改，比如更改了maven插件、增加了npm的过程等 	
- ci 持续集成方面的更改。现在有些build系统喜欢把ci功能使用yml描述。如有这种更改，建议使用ci
- chore 其他改动。比如一些注释修改或者文件清理。不影响src和test代码文

五、核心代码

.releaserc文件
注意：

• 我们这里额外引用了@semantic-release/npm这个包，npmPublish即是执行发布，会帮助我们执行自动化的发布，pkgRoot为要发布的文件夹包，需要包含package等文件，同时大家也需要按照token或者用户账户密码的形式写入到git CI的临时变量中去，这个是重点。

  • 
    

• branches中的name与prerelease则是会执行job的分支和是否发布

{
  "branches": ["+([0-9])?(.{+([0-9]),x}).x", "master", "next", "next-major", {"name": "beta", "prerelease": true}, {"name": "alpha", "prerelease": true}],
  "plugins": [
    ["@semantic-release/commit-analyzer",{
      "preset": "angular",
      "releaseRules": [
        {"type": "docs", "scope":"README", "release": "patch"},
        {"type": "refactor", "release": "patch"},
        {"type": "style", "release": "patch"}
      ],
      "parserOpts": {
        "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES"]
      }
    }],
    "@semantic-release/release-notes-generator",
    ["@semantic-release/npm", {
      "npmPublish": true,
      "pkgRoot": "packages/ests-sdk-ali"
    }],
    "@semantic-release/changelog",
    [
      "@semantic-release/git",
      {
        "assets": [
          "package.json",
          "CHANGELOG.md"
        ],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ]
  ]
}

.gitlab-ci.yml 文件
共计4个job任务，test是执行单元测试的任务、alphaPublish自动化发布alpha版本、betaPublish自动化发布alpha版本、releasePublish自动化发布正式稳定版本

stages:
  - test
  - alphaPublish
  - betaPublish
  - releasePublish
test:
  stage: test
  image: node:lts
  script:
    - npm i
    - npm run test
    - npm run build
  only:
    - alpha
  tags:
    - runner-web
alphaPublish:
  stage: alphaPublish
  image: node:lts
  script:
    - npx --no-install semantic-release
  dependencies: [] 
  only:
    - alpha
  tags:
    - runner-web
betaPublish:
  stage: betaPublish
  image: node:lts
  script:
    - npm i
    - npm run build
    - npx --no-install semantic-release
  dependencies: []    
  only:
    - beta
  tags:
    - runner-web
releasePublish:
  stage: releasePublish
  image: node:lts
  script:
    - npm i
    - npm run build
    - npx --no-install semantic-release
  dependencies: []
  # 仅在中央仓库的分支发生提交时才触发 release 流程       
  only:
    - master
  tags:
    - runner-web

这里仅仅只使用于单个的包发布，或者通过代码构建把不同的包区分在了不同的文件夹中。可以通过执行多个npm，如：

 ["@semantic-release/npm", {
   "npmPublish": true,
   "pkgRoot": "packages/ests-sdk-ali"
 }],
 ["@semantic-release/npm", {
   "npmPublish": true,
   "pkgRoot": "packages/ests-sdk-baidu"
 }],
 ["@semantic-release/npm", {
   "npmPublish": true,
   "pkgRoot": "packages/ests-sdk-tt"
 }]

六、效果预览

问题：

npm ERR! code E404
npm ERR! 404 Not Found - PUT https://registry.npmjs.org/xxx%2fali - Not found
npm ERR! 404 
npm ERR! 404  '@ests-sdk/xx' is not in this registry.
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

通常在执行时会发现检测通过了，但是发布时报错404，这是因为在npm初始化时需要手动建立一个组织，这里是ests-sdk的一个组织，才能发布@ests-sdk/xxx的npm包

下一文，我们来讲述一下通过lerna来发布多包该如何执行自动化的规范。