如何設計npm包的開發和發布流程

qieangel2013 發布于2019-08-23 17:02 / 3003人閱讀

摘要：所以此版本號在這里的作用并不是用來區分版本的，小版本號才是真正用來做版本區分的，那么在引用這個就要這么來控制版本號，舉個栗子鎖定大版本號和小版本號，不管我們開發過程中提交了多少次，我們引用都是最新的。

最近在把公司內部用的一個庫發布到內網的npm私服上，僅僅是發布的話是比較簡單的，但這個庫是由多個人一起維護的，而且npm私服只有一套，所以生產環境和開發環境，用的是同一個，那么，我們的需求來了：如何設計npm包的開發流程和自動化發布流程。這一套流程我們想要的達成如下目標

支持團隊協作，有開發提交代碼，其他人能及時同步到最新代碼

能夠支持常規迭代和hotfix上線

同一版本開發、測試、生產環境的引用包的版本號都是一致的

自動化發布，減少人工操作

先說下如何搭建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 [ | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=] | 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 的一些步驟和配置項。

項目開啟CI，選擇一個公共的 runner，要是沒有，那就只能自己弄一個。

項目根目錄新建 .gitlab-ci.yml，寫入配置，詳細的配置可以查看 gtilab官網

# 定義 stages
stages:
  - build

定義 job
job1:
  stage: build
  script:
    - echo "xxx"

配置完成

設計階段

我們要說的重點來啦，通過畫圖的方式來給大家介紹我們的設計思路。先來設定些約定

分支的約定

項目的分支的規劃，設定三個分支

feature分支：常規功能迭代

master分支：穩定分支

hotfix分支：當有緊急修改時，創建該分支，作為臨時修復分支，這樣可以不影響常規功能的開發

版本號的約定

我們采用 大版本:小版本:次版本號 這種方式，每一次feature分支上的每次提交都觸發此版本號升級，比如當前feature分支的版本號是 1.1.5 那么下一次提交就會升級為 1.1.6 并發布npm，小版本號跟著常規需求迭代往上升級，比如說當前是 1.1.8 ，周期性的需求在明天上線，那么上線后，版本號就升級為 1.2.0 并發布npm，大家發現 1.1.8 和 1.2.0 是同樣的代碼，沒錯，之所以這么做是因為小版本號對應的是一個周期的常規修改，那么升級的 1.2.0 就是作為下一次的常規需求的版本號，這樣一來，此版本號對應的是每一次提交，小版本號對應的是當前的開發階段，這兩個我們都可以通過CI來觸發修改，不需要人工參與，剩下還有個大版本號，這個只有在大改版的情況下才由人工修改，一般來說升級大版本號的頻率是比較低的，人工來來修改完全是OK的。

大家會發現每一次提交就觸發 npm version patch & npm publish 感覺太頻繁了，但為了能滿足團隊協作，只好做些小小的讓步。所以此版本號在這里的作用并不是用來區分版本的，小版本號才是真正用來做版本區分的，那么在引用這個npm就要這么來控制版本號，舉個栗子

"my-package": "~1.2.0"

鎖定大版本號和小版本號，不管我們開發過程中提交了多少次，我們引用都是最新的。

時序圖

畫了開發、發布的時序圖，如下。

開發流程時序圖

開發時序圖如下

發布流程時序圖

編碼實現

主要是CI的編碼，如下

# .gitlab-ci.yml
# 定義 stages
stages:
  - publish

# 定義 job
job2:
  stage: publish
  before_script:
    - cd /home/node/MY #進到項目目錄
    - git checkout .
    - git checkout $CI_COMMIT_REF_NAME || git checkout -b $CI_COMMIT_REF_NAME
    - git pull -f -X theirs origin $CI_COMMIT_REF_NAME
    - yarn
  script:
    - node publish.js

// publish.js
var shell = require("shelljs");
var git = require("git-last-commit");
var featureBranchName = "feature-npm";
// 判斷文本是否是版本號格式
function checkCommitMessage(subject) {
    return /^d+.d+.d+$/g.test(subject)
}

// 獲取最近一次提交，判斷是否是版本號格式，若不是，則進行發布，
git.getLastCommit(function(err, commit) {
    console.log(commit);
    const { subject, sanitizedSubject } = commit;
    shell.exec("echo $CI_COMMIT_REF_NAME");

    if (!checkCommitMessage(subject)) {
        if (sanitizedSubject.indexOf(`Merge-branch-${featureBranchName}-into-master`) > -1) {
            shell.exec("git checkout .");
            shell.exec(`git checkout ${featureBranchName} || git checkout -b ${featureBranchName}`);
            shell.exec(`git pull -f -X theirs origin ${featureBranchName}`);
            shell.exec("npm version minor");
            shell.exec("npm publish");
            shell.exec(`git push origin ${featureBranchName}`);
        } else {
            shell.exec("npm version patch");
            shell.exec("npm publish");
            shell.exec("git push origin $CI_COMMIT_REF_NAME");
        }
     }
});

// package.json
"scripts": {
    "test": "echo "Error: no test specified" && exit 1",
    "prepublish": "build script"
  },

發布腳本里有個函數 checkCommitMessage 用于判斷最新的提交message是不是版本號格式，因為我們最后會有一步push的操作，push后會再一次觸發CI，所以為了防止死循環，我們通過提交的message作為是否觸發CI的依據，這么一來我們就要規范message的格式，我的建議是按照這個格式 U ${修改的具體的內容}。

小結

這個方案不是個普適性的方案，畢竟每個團隊的開發流程都不一樣，目前這個方案是適合我們目前的場景的。如果有小伙伴的場景跟我們的一致，可以嘗試下，如果小伙伴們有更好的方案，歡迎一起交流呀~

GPU云服務器云服務器小程序的開發和發布前端開發和前端設計前端設計和前端開發 GitHub發現“tar”和 npm C

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/103717.html

減小發布到npm包的體積與避免重復依賴

摘要：我們可以把未經過打包的源代碼發布到，并把中的字段指向源代碼，這樣引入的就交由項目的構建工具來進行處理，因此理論上就可以避免重復依賴了。總結通過這兩天的折騰，主要收獲有點發布包的流程中的字段判斷重復依賴的機制基于組件封裝組件時如何避免重復依賴這兩天一直在忙于封裝一個vue table組件并發布到npm，記錄一下我是如何把npm包的大小從100多kb減小到不足1kb的過程。背景這個組...

xiaotianyi 2019-08-23 13:04 評論0 收藏0
前端每周清單第 47 期：NPM 年度報告與 2018 展望，Airbnb React Router

摘要：確定新的包命名規則為了盡可能避免包的誤植域名現象，將不會再允許使用相似的包命名不過會進一步鼓勵開發者使用自己的命名空間來發布包。本文是對其幾十年來技術之路的回顧與展望，也是一代技術人的青春回憶。 showImg(https://segmentfault.com/img/remote/1460000012846628); 前端每周清單專注前端領域內容，以對外文資料的搜集為主，幫助開發者了...

makeFoxPlay 2019-08-22 13:50 評論0 收藏0
如何發布你自己的React模塊至NPM

摘要：文章介紹如何創建發布一個包，包括項目搭建發布流程注意事項等。語義化版本號分為三位。主版本號當進行了大都改動或者對有很多不兼容修改時應該進行版本號升級。次版本號增加了部分特性或者優化時升級該版本。如如果你想撤回指定版本，執行包名版本號。文章介紹如何創建發布一個npm包，包括項目搭建、發布流程、注意事項等。演示代碼GitHub地址 1. 初始化項目首先在創建好的項目文件夾下面執行 ...

zombieda 2019-08-23 14:48 評論0 收藏0
幾分鐘的閱讀讓你明白node.JS的強大走上web后端開發的道路（一版）

摘要：這些特性不僅帶來了大的性能提升，還減少多線程程序設計的復雜性，進而提高了開發效率。由公司建立的云計算平臺率先支持了。前言本文章主要寫給那些想了解node語言的開發,我的目標希望大家通過閱讀本篇文章能夠簡單使用node進行開發，以及了解一些事件驅動的異步編程風格,主要分node的背景,安裝配置,模塊創建引用等幾個方面描述建議大家在閱讀本篇文章途中可以親自嘗試一下我所帶來的小例子，...

libxd 2019-08-21 18:25 評論0 收藏0
發布 react 組件到 npm 上

摘要：我發布了我的第一個組件，一個基于的標簽云組件。然后將這個編譯命令寫到里，如下那么以后要編譯下面的代碼，只需要執行現在我們已經有編譯好的代碼了，接下來就可以發布到供其他人使用了。我發布了我的第一個 npm 組件，一個基于 react 的 3d 標簽云組件。在這途中我也是遇到了很多的坑，花在完善整個發布流程的時間遠多于寫這個組件本身的時間，所以我記錄下我覺得一個正常的 react 組件的...

Yi_Zhi_Yu 2019-08-23 15:05 評論0 收藏0