私有npm計劃

 

爲何要創建私有npm

1. 提升代碼複用程度，增長團隊沉澱
2. 剝離項目依賴，工程更加輕量
3. 引用全量更新，支持版本降級
4. 創建模塊文檔，下降上手難度
5. 全員把關代碼質量，無需重複測試
6. 構建工具已成趨勢，優化發佈流程，減小手動工做，提升團隊效率
7. 加強團隊代碼交流
8. 內部保密機制

要作的工做

1. 搭建私有 npm 環境
2. 探索 npm 使用工做流
3. npm 對接 OA，作好權限控制
4. npm 上傳規範制定
5. 現有組件上傳 npm 要作的改造
6. 使用 git 維護源碼庫
7. git 與 npm publish 聯動，實現自動測試、構建、發佈、回滾

 

基於cnpm的私有npm搭建

爲何選擇 cnpm?

1. taobao 出品，通過大流量考驗
2. 國內大多數公司部署私有 npm 的選擇
3. 完整接口，減低二次開發難度
4. 部署友好，支持 msyql，數據遷移方便
5. 較爲完善的 markdown 支持，文檔友好
6. 完善客戶端支持，豐富的工做流選項
7. 實際上沒有不少別的解決方案，官方工具須要使用 coachDB，sinopia 過於迷你，沒有數據庫支持，且對 markdown 支持很差

部署過程

// TODO 
//　其實已經搭建好了，超簡單，有時間把詳細過程下來:>

遇到問題

1. 須要定義公司前綴，對項目侵入較大，使用了私有 npm 的項目必須使用 cnpm 安裝，或指定 registry 安裝，這就致使公共模塊的包也會向私有 npm 請求，私有 npm 再從 taobao 源請求，可能會致使必定的延遲
2. 須要在配置中指定管理員用戶， 只有管理員用戶才能 publish 項目，須要探索一下是否可以接入 oa 驗證
3. 默認界面太醜，能夠優化一下，打上咱們本身的標記

私有npm使用工做流

使用私有 npm 的幾種方式

npm 有一個叫作 registry(源) 的配置項，相似於 linux 中的軟件源的概念，這項配置指定 npm 應該以哪一個地址爲遠程倉庫，有了遠程倉庫，npm 纔可以下載、發佈這些代碼。

因此，要使用私有 npm，就在於改變這個 regisitry 配置項，npm 爲咱們提供了兩種方式來改變(也可能有多種，我常使用的就以下兩種)：

1. 直接修改 npm 全局配置，以下：

1. npm config set registry http://npm.corp.chinahr.com

這樣的好處是一次修改，永久使用，不須要再次設置，缺點是，這個地址並非隨時隨地能夠訪問，由於是公司內網地址，對開發者侵入較大。

1. 在每次執行 npm 命令的時候，後面加上 --registry 參數。

1. npm install vue --registry http://npm.corp.chinahr.com

這樣作的好處是比較靈活，能夠隨意指定 registry 地址，而且本次生效，缺點是每次都須要手動輸入 registry 地址。

因此這兩種都不是完美的方案，cnpm 也提供了另外兩種方案：

1. 安裝 cnpm 客戶端(也是個 npm 程序)，這個客戶端包含了 npm 全部的命令，將這個客戶端的 registry 設置爲私有 npm 的地址，之後使用 cnpm 進行代替。
2. 設置一個 alias 新命令，將私有 npm 的 registry 設置爲默認，之後使用這個 alias 代替 npm 詳細設置方法。

這四方法均可以使用使用 私有 npm，每一個方法的缺點是：

1. 對開發環境侵入較大，若是沒有公司內網環境，則沒法使用 npm， 須要切換回來；
2. 使用繁瑣；
3. 新引入一個命令，沒法和現有腳手架和自動化工具融合，其實 2 也有相似問題；
4. 同 3，並且對 windows 系統不友好。

因此仍是並無什麼完美的解決方案，最推薦的方案是 3

在之後的文檔說明中，cnpm　命令即表明正確地使用私有 npm

下載 package

和 npm install 沒什麼區別，只是須要在包名前面加上公司前綴 @chr/，這是由於 cnpm 的定位是一個 npm 鏡像的全量同步工具，這樣設置是防止與npmjs.org 中的 package 發生衝突 
例如：私有 npm 中有一個叫作 webpack 的包，下載的時候須要這樣：

1. cnpm install @chr/webpack

發佈 package

發佈 package 須要預先在配置文件中受權，這個等到我們的 oa 接入了， 就能夠配置好權限，作到全部人均可以發佈。 
發佈 package 的步驟：

1. cnpm init　 
   在這個模塊下建立 package.json，讓這個文件夾下的文件受 npm 管理，注意項目名稱前應該加上@chr/
2. 完善文檔信息 
   修改項目的 README 文件，對項目作一個簡要的說明
3. 完善版本號 
   若是是初次發佈的項目，版本號無需處理，若是是對項目進行更新，則應該先修改版本號，不然沒法發佈
4. cnpm login 
   在命令行中登錄 npm，這個後期會和 oa 進行聯動，如今的狀態是，若是沒有用戶會自動註冊，這裏建議使用 oa 帳號，方便之後對接。 
   5.　cnpm publish 
   　發佈 package 
   　

待解決的問題

1. npm 會自動安裝最新版本的 package，若是某個 package 版本更新通知沒有作到位，可能會致使接口升級致使的現有代碼受影響的狀況

發佈 package規範

搭建私有npm 最大的意義就是可以複用咱們核心代碼，提升開發效率，因此對上傳上來的代碼要有一個嚴格的規範，這樣可以保證代碼質量，減小溝通成本，防止協做的時候產生混亂。

這個規範須要一塊兒來討論制定，我先把我想到的幾點寫出來，你們一塊兒完善

README.md

文檔對於模塊化項目來講十分重要，經過文檔，調用者可以對項目的基本功能一目瞭然，迅速瞭解這個項目解決了什麼問題、如何調用、存在什麼問題，而不須要去與項目的維護者進行溝通。 
npm 有默認的 package 自文檔管理方案，即經過項目內的 README.md 
項目文檔應該至少包含如下幾個方面：

1. 解決了什麼問題
2. 包含那些組件
3. 如何調用
4. 有哪些配置項
5. 存在哪些問題
6. 更新計劃: 長期/快速迭代

example

應該包含其中項目中各個方法的示例程序

測試

做爲基礎模塊，單元測試必不可少，基礎模塊也很適合作單元測試

測試這塊，我沒有什麼經驗，你們能夠一塊兒探索

review

重要模塊的更新及上線，應該由團隊大多數人進行 review

npm script

更新通知