npm 進階命令知多少(一)
npm命令知多少(一)
前言
作為前端模組化扎展現形式的npm包，已經在前端開發中不可或缺，熟練掌握npm相關內容，也是前端開發者的一門必修課，那麼除了npm publish這類常見內容之外，還有哪些內容需要我們關注呢，下面就一起深入看看。
npm publish 發布npm包
該命令簡單粗暴，執行之後，就會將相關文件上傳到遠端，並為對應包新增一個對應版本號。那麼這裡的相關文件和對應版本具體是哪些呢，不知道大家有沒有關注過。
發布哪些文件
一個指令爽的飛起，包發布完成了，問題是發了什麼上去呢，萬一有些不能對外暴露的文件被download下去，問題可能就大了。因此npm允許開發者通過配置來指定待發布內容。
可以分為以下幾種情況來指定:
- 當前包目錄下，只要.npmignore存在，那麼以.npmignore為準，沒有被.npmignore忽略的內容都會被上傳，即使.gitignore已經忽略該文件。畢竟是專用配置文件，優先順序最高。
- 不存在.npmignore，但有.gitignore，會以.gitignore為準。這裡也說得過去，一般無需通過git進行管理的文件，一般是無關內容，例如.vscode等環境配置相關。
例如，vue就只有 .gitignoe 大家可以看下安裝的包裡面存不存在相關文件。 - 沒有.gitignore 或者 .npmignore，上所有文件都會上傳。
- 有一種情況例外，package.json中存在files欄位，可以理解為files為白名單，ignore文件為黑名單。
files:["src","types"]
這裡有個問題：當.npmignore和files內容衝突時，那個優先順序高呢。答案是以files為準,
可以通過npm pack 命令進行本地測試：
// .npmignore
.DS_Store
node_modules
.gobble*
dist
src
// package.json
"files": [
"src",
"dist",
"README.md"
]
// 打包測試
npm pack
項目根目錄下會生成一個壓縮包這就是將要上傳的文件內容，打開後可以發現，src文件夾是存在的。
舉個栗子
再舉個比較明顯的例子，[email protected] 其配置如下：
//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相同，上面的例子也體現出了相關語法，這裡就不粘貼了。
至於什麼樣的文件夾可以被認定為包目錄：
這裡的定義比較複雜
常見的就是包含有package.json的文件夾，我們記住這個就行了。
具體到實際開發中，monorepo那種單倉庫多包的形式，每個子包顯然也是一個包目錄，可以進行獨立的npm包管理行為。
舉個例子：
- vue下的packages的vue-template-compiler ，就是單獨發布為一個vue-template-compiler包的。
- 根目錄發布為vue包，忽略掉了packages下的一些內容
總結
這一小段的核心就是，指定需要上傳的文件時有兩種方式：
- 白名單形式： files欄位，優先順序最高，該欄位以外的文件，除了資訊類，其他的都忽略。
適用於，文件夾多，需要上傳的文件夾少的情況，例如vue這種。 - 黑名單形式: .npmignore 或.gitignore， npmignore優先順序較高。
- 都不指定，包目錄下所有內容都上傳。
發布希么版本
明確了發布的內容之後，發布的版本也是有要求的。通用的就是遵循語義化版本規範，部分內容摘抄如下：
版本格式：主版本號.次版本號.修訂號，
版本號遞增規則如下：
主版本號：當你做了不兼容的 API 修改，
次版本號：當你做了向下兼容的功能性新增，
修訂號：當你做了向下兼容的問題修正。
先行版本號及版本編譯元數據可以加到「主版本號.次版本號.修訂號」的後面，作為延伸。
先行版本：
alpha: 內部版本
beta: 公測版本
rc: 即Release candiate，正式版本的候選版本
作為業界公認的規範，只有大家都遵循之後，才能形成整個生態的統一和諧，否則一方升級版本之後，使用者都不敢跟進，那麼就不要談以後的發展了。
版本哪裡來
版本通過package.json裡面的version欄位來確定：
"version": "1.0.0",
每一版本號是唯一的，假如發布了1.0.0,下次更新必須要進行更新，否則會提醒。
npm ERR! [forbidden]cannot modify pre-existing version: 1.0.1
自動更新
有人說，每次都要手動更新版本太麻煩，或者萬一改錯了就不好了。 是否有命令行可以替我自動執行這些操作。
這裡要說一下，因為版本的確定還是一個依賴於內容決定的主觀性動作，所以不可能全自動的通過工具實現，誰知道你改的內容是否向下兼容，這裡作為開發者要有自己的判斷。
因此只能實現個半自動操作:
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，可以通過下面的指令避免：
npm --no-git-tag-version version
舉個例子：
// 當前版本 1.0.0
"version": "1.0.0",
// 升級大版本好
npm version major
// 執行後當前結果
"version": "2.0.0",
總結
這一節的重點就在於介紹了升級版本的半自動操作，雖然本地開發時看起來半自動提升不明顯。
但是在ci/cd中，就可以結合git，實現升版本，push程式碼的聯合操作。
避免忘記修改版本重新發布的情況。
誰來發布
前面講到了發布npm的直接一步，但這之前還需要個前置步驟。那就是登錄了，否則作為一個成熟的系統，遊客隨便就進行修改操作了，那也太可怕了。
常規操作：
npm login
-> npm login
Username:
Password:
Email: (this IS public)
依次執行就可以了，假如不確定是否登錄，可以通過查看命令來看：
npm whoami
登錄完成之後，不一定可以發布指定包，需要具備許可權（這也是要我們登錄的原因，鑒權嘛），假如沒有，可以讓有許可權的同學通過下面命令添加：
// 給zhangshan增加pkg1 包的發布許可權
npm owner add zhangshan pkg1
假如某一天登錄態過期了，那麼我們又要重新執行這些操作了。那麼是否可以有方式配置自己的登錄態呢，這就要依賴.npmrc這個文件了。
npmrc
npm的配置文件，相關配置項可以參考：//www.npmjs.cn/misc/config/
例如我們常見的修改為淘寶源，除了通過如下命令行的形式外：
npm config set registry //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的形式。
舉個例子：
// 隨手從網上找了個：
prefix=D:\Program Files\nodejs\node_global
cache=D:\Program Files\nodejs\node_cache
registry=//registry.npm.taobao.org
假如要修改用戶名，在其中進行修改即可。
結束語
本來想一篇就把npm的相關內容介紹完畢，沒想到隨便展開一下就很多了，本文就到這裡吧，其他的後面再行更新。本文是一篇學習筆記，部分內容沒有展開講，有興趣的同學可以直接官網深究。
因為精力和能力有限，如果有疏漏，忘不吝指正。
更多部落格請轉
