npm 進階命令知多少(一)

瀟湘待雨發表於2020-09-08
NPM

npm命令知多少(一)

前言

作為前端模組化扎展現形式的npm包，已經在前端開發中不可或缺，熟練掌握npm相關內容，也是前端開發者的一門必修課，那麼除了npm publish這類常見內容之外，還有哪些內容需要我們關注呢，下面就一起深入看看。

npm publish 釋出npm包

該命令簡單粗暴，執行之後，就會將相關檔案上傳到遠端，併為對應包新增一個對應版本號。那麼這裡的相關檔案和對應版本具體是哪些呢，不知道大家有沒有關注過。

釋出哪些檔案

一個指令爽的飛起，包釋出完成了，問題是發了什麼上去呢，萬一有些不能對外暴露的檔案被download下去，問題可能就大了。因此npm允許開發者通過配置來指定待發布內容。
可以分為以下幾種情況來指定:

  1. 當前包目錄下，只要.npmignore存在，那麼以.npmignore為準，沒有被.npmignore忽略的內容都會被上傳，即使.gitignore已經忽略該檔案。畢竟是專用配置檔案，優先順序最高。
  2. 不存在.npmignore，但有.gitignore，會以.gitignore為準。這裡也說得過去，一般無需通過git進行管理的檔案，一般是無關內容，例如.vscode等環境配置相關。
    例如，vue就只有 .gitignoe 大家可以看下安裝的包裡面存不存在相關檔案。
  3. 沒有.gitignore 或者 .npmignore，上所有檔案都會上傳。
  4. 有一種情況例外，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資料夾是存在的。

舉個例子
再舉個比較明顯的例子，vue@2.6.12 其配置如下：

//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包管理行為。

舉個例子：

總結

這一小段的核心就是，指定需要上傳的檔案時有兩種方式：

  1. 白名單形式： files欄位，優先順序最高，該欄位以外的檔案，除了資訊類，其他的都忽略。
    適用於，資料夾多，需要上傳的資料夾少的情況，例如vue這種。
  2. 黑名單形式: .npmignore 或.gitignore， npmignore優先順序較高。
  3. 都不指定，包目錄下所有內容都上傳。

釋出什麼版本

明確了釋出的內容之後，釋出的版本也是有要求的。通用的就是遵循語義化版本規範，部分內容摘抄如下：

版本格式：主版本號.次版本號.修訂號，

版本號遞增規則如下：

主版本號：當你做了不相容的 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的配置檔案，相關配置項可以參考：https://www.npmjs.cn/misc/config/
例如我們常見的修改為淘寶源，除了通過如下命令列的形式外：

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的形式。
舉個例子：

// 隨手從網上找了個：
prefix=D:\Program Files\nodejs\node_global
cache=D:\Program Files\nodejs\node_cache
registry=https://registry.npm.taobao.org

假如要修改使用者名稱，在其中進行修改即可。

結束語

本來想一篇就把npm的相關內容介紹完畢，沒想到隨便展開一下就很多了，本文就到這裡吧，其他的後面再行更新。本文是一篇學習筆記，部分內容沒有展開講，有興趣的同學可以直接官網深究。
因為精力和能力有限，如果有疏漏，忘不吝指正。
更多部落格請轉

相關文章