# npm命令知多少(一) ## 前言 作為前端模組化扎展現形式的npm包，已經在前端開發中不可或缺，熟練掌握npm相關內容，也是前端開發者的一門必修課，那麼除了npm publish這類常見內容之外，還有哪些內容需要我們關注呢，下面就一起深入看看。 ## npm publish 釋出npm包 該命令簡單粗暴，執行之後，就會將相關檔案上傳到遠端，併為對應包新增一個對應版本號。那麼這裡的**相關檔案**和**對應版本**具體是哪些呢，不知道大家有沒有關注過。 ### 釋出哪些檔案 一個指令爽的飛起，包釋出完成了，問題是發了什麼上去呢，萬一有些不能對外暴露的檔案被download下去，問題可能就大了。因此npm允許開發者通過配置來指定待發布內容。 可以分為以下幾種情況來指定: 1. 當前包目錄下，只要.npmignore存在，那麼以.npmignore為準，沒有被.npmignore忽略的內容都會被上傳，即使.gitignore已經忽略該檔案。畢竟是專用配置檔案，優先順序最高。 2. 不存在.npmignore，但有.gitignore，會以.gitignore為準。這裡也說得過去，一般無需通過git進行管理的檔案，一般是無關內容，例如.vscode等環境配置相關。 例如，[vue就只有](https://github.com/vuejs/vue/blob/dev/.gitignore) .gitignoe 大家可以看下安裝的包裡面存不存在相關檔案。 3. 沒有.gitignore 或者 .npmignore，上所有檔案都會上傳。 4. 有一種情況例外，package.json中存在files欄位，可以理解為files為白名單，ignore檔案為黑名單。 ```js files:["src","types"] ``` 這裡有個問題：當.npmignore和files內容衝突時，那個優先順序高呢。**答案是以files為準**, 可以通過npm pack 命令進行本地測試： ```js // .npmignore .DS_Store node_modules .gobble* dist src // package.json "files": [ "src", "dist", "README.md" ] // 打包測試 npm pack ``` 專案根目錄下會生成一個壓縮包這就是將要上傳的檔案內容，開啟後可以發現，src資料夾是存在的。 **舉個栗子** 再舉個比較明顯的例子，[[email protected]](https://github.com/vuejs/vue/tree/v2.6.12) 其配置如下： ```js //files "files": [ "src", "dist/*.js", "types/*.d.ts" ] // .gitignore .DS_Store node_modules *.log explorations TODOs.md dist/*.gz dist/*.map dist/vue.common.min.js test/e2e/reports test/e2e/screenshots coverage RELEASE_NOTE*.md dist/*.js packages/vue-server-renderer/basic.js packages/vue-server-renderer/build.js packages/vue-server-renderer/server-plugin.js packages/vue-server-renderer/client-plugin.js packages/vue-template-compiler/build.js .vscode ``` 這樣的話，vue對外開放的npm包中，只包含有files定義的檔案和package.json、README.md這些文件類檔案。 為什麼有額外這些文件類呢，原因在於這些資訊傳遞的檔案，npm是規定不允許忽略的，只有存在就會上傳： * package.json * README (and its variants) * CHANGELOG (and its variants) * LICENSE / LICENCE **ignore語法格式** .npmignore語法跟.gitignore相同，上面的例子也體現出了相關語法，這裡就不貼上了。 **至於什麼樣的資料夾可以被認定為包目錄**： [這裡的定義比較複雜](https://docs.npmjs.com/using-npm/developers) 常見的就是包含有package.json的資料夾，我們記住這個就行了。 具體到實際開發中，monorepo那種單倉庫多包的形式，每個子包顯然也是一個包目錄，可以進行獨立的npm包管理行為。 舉個例子： * [vue下的packages的vue-template-compiler](https://github.com/vuejs/vue/tree/dev/packages/vue-template-compiler) ，就是單獨釋出為一個vue-template-compiler包的。 * 根目錄釋出為vue包，忽略掉了packages下的一些內容 #### 總結 這一小段的核心就是，指定需要上傳的檔案時有兩種方式： 1. 白名單形式： files欄位，優先順序最高，該欄位以外的檔案，除了資訊類，其他的都忽略。 適用於，資料夾多，需要上傳的資料夾少的情況，例如vue這種。 2. 黑名單形式: .npmignore 或.gitignore， npmignore優先順序較高。 3. 都不指定，包目錄下所有內容都上傳。 ### 釋出什麼版本 明確了釋出的內容之後，釋出的版本也是有要求的。通用的就是[遵循語義化版本規範](https://semver.org/lang/zh-CN/ )，部分內容摘抄如下： ```js 版本格式：主版本號.次版本號.修訂號， 版本號遞增規則如下： 主版本號：當你做了不相容的 API 修改， 次版本號：當你做了向下相容的功能性新增， 修訂號：當你做了向下相容的問題修正。 先行版本號及版本編譯元資料可以加到“主版本號.次版本號.修訂號”的後面，作為延伸。 先行版本： alpha: 內部版本 beta: 公測版本 rc: 即Release candiate，正式版本的候選版本 ``` 作為業界公認的規範，只有大家都遵循之後，才能形成整個生態的統一和諧，否則一方升級版本之後，使用者都不敢跟進，那麼就不要談以後的發展了。 **版本哪裡來** 版本通過package.json裡面的version欄位來確定： ```js "version": "1.0.0", ``` 每一版本號是唯一的，假如釋出了1.0.0,下次更新必須要進行更新，否則會提醒。 ```js npm ERR! [forbidden]cannot modify pre-existing version: 1.0.1 ``` **自動更新** 有人說，每次都要手動更新版本太麻煩，或者萬一改錯了就不好了。 是否有命令列可以替我自動執行這些操作。 這裡要說一下，因為版本的確定還是一個依賴於內容決定的主觀性動作，所以不可能全自動的通過工具實現，誰知道你改的內容是否向下相容，這裡作為開發者要有自己的判斷。 因此只能實現個半自動操作: ```js npm version opt // 這裡opt 的取值如下，跟語義化版本是對應的。 patch, minor, major, prepatch, preminor, premajor, prerelease ``` 官方解釋： Run this in a package directory to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json. 不僅會根據指令自動升級版本，升級幅度為1。而且會回寫到下面檔案中package.json, package-lock.json, and, if present, npm-shrinkwrap.json。 這裡有個點需要注意，如果是在git倉庫下，還會自動建立一個版本commit和tag，可以通過下面的指令避免： ```js npm --no-git-tag-version version ``` 舉個例子： ```js // 當前版本 1.0.0 "version": "1.0.0", // 升級大版本好 npm version major // 執行後當前結果 "version": "2.0.0", ``` #### 總結 這一節的重點就在於介紹了升級版本的半自動操作，雖然本地開發時看起來半自動提升不明顯。 但是在ci/cd中，就可以結合git，實現升版本，push程式碼的聯合操作。 避免忘記修改版本重新發布的情況。 ### 誰來發布 前面講到了釋出npm的直接一步，但這之前還需要個前置步驟。那就是登入了，否則作為一個成熟的系統，遊客隨便就進行修改操作了，那也太可怕了。 常規操作： ```js npm login -> npm login Username: Password: Email: (this IS public) ``` 依次執行就可以了，假如不確定是否登入，可以通過檢視命令來看： ```js npm whoami ``` 登入完成之後，不一定可以釋出指定包，需要具備許可權（這也是要我們登入的原因，鑑權嘛），假如沒有，可以讓有許可權的同學通過下面命令新增： ```js // 給zhangshan增加pkg1 包的釋出許可權 npm owner add zhangshan pkg1 ``` 假如某一天登入態過期了，那麼我們又要重新執行這些操作了。那麼是否可以有方式配置自己的登入態呢，這就要依賴.npmrc這個檔案了。 #### npmrc npm的配置檔案，相關配置項可以參考：[https://www.npmjs.cn/misc/config/](https://www.npmjs.cn/misc/config/) 例如我們常見的修改為淘寶源，除了通過如下命令列的形式外： ```js npm config set registry https://registry.npm.taobao.org ``` 還可以通過.npmrc來配置 #### .npmrc的位置 作為基本的配置項，npm的設定還是非常靈活的，允許使用者自定義來滿足定製化需求，但是使用者一般只會修改幾項，所以一般我們會遇到四個是.npmrc的檔案： * 每個專案的配置檔案，位置是： (/path/to/my/project/.npmrc) * 每個使用者的配置檔案，位置是：(~/.npmrc) 因為每個計算機可以有多個使用者。 * 全域性配置檔案，位置是 ($PREFIX/etc/npmrc) * npm 內建配置檔案，位置是 (/path/to/npm/npmrc) 全域性都有了，為啥還有個內建呢，避免不完全修改，做個備份。 **這四個檔案的優先順序是自上而下元件減小的** 這樣也可以理解，使用者的修改專案本地檔案是最低成本且不會造成其他影響的，所以優先順序最高，npm內建的優先順序最低。 其內容都是key-value的形式。 舉個例子： ```js // 隨手從網上找了個： prefix=D:\Program Files\nodejs\node_global cache=D:\Program Files\nodejs\node_cache registry=https://registry.npm.taobao.org ``` 假如要修改使用者名稱，在其中進行修改即可。 ## 結束語 本來想一篇就把npm的相關內容介紹完畢，沒想到隨便展開一下就很多了，本文就到這裡吧，其他的後面再行更新。本文是一篇學習筆記，部分內容沒有展開講，有興趣的同學可以直接[官網深究](https://docs.npmjs.com/cli-documentation/)。 因為精力和能力有限，如果有疏漏，忘不吝指正。 [更多部落格請轉](http://xxdy.tech/2020/09/06