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

舉個例子：

• vue下的packages的vue-template-compiler ，就是單獨發佈爲一個vue-template-compiler包的。
• 根目錄發佈爲vue包，忽略掉了packages下的一些內容

總結

這一小段的核心就是，指定須要上傳的文件時有兩種方式：

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的相關內容介紹完畢，沒想到隨便展開一下就不少了，本文就到這裏吧，其餘的後面再行更新。本文是一篇學習筆記，部份內容沒有展開講，有興趣的同窗能夠直接官網深究。
由於精力和能力有限，若是有疏漏，忘不吝指正。
更多博客請轉