前端三十｜24. [BE] 請說明一下 npm 的套件管理機制

在現代的網站中，使用他人開放原始碼的套件輔助開發已經是稀鬆平常的事情，無論是透過套件加速堆砌產品，或是在開發環境中加上協助工程師的各式工具，只需要稍加設定，一個專案便能輕易加載了成千上萬的外部程式；但如此方便的機制，究竟是怎麼實現的呢？

本系列文已經重新編校彙整編輯成冊，並正式出版囉！

《前端三十：從 HTML 到瀏覽器渲染的前端開發者必備心法》好評販售中！

喜歡我文章內容的讀者們，歡迎您前往購買支持！

套件管理工具

對前端開發者來說，最熟悉的應該是安裝 Node.js 時自動附帶的 npm 吧？npm 即為 Node Package Manager 的縮寫，開發者可以透過 Node 隨附的 npm cli，進行套件的安裝及管理。

例如在專案資料夾的終端機中輸入 npm install express，npm 便會自動從 Registry 中尋找 express 這個非常熱門的 Node.js Web Server 框架，取得最新版本，下載到專案中的 node_modules 資料夾中。

然而在專案中，不可能每次都透過開發者自行指定套件安裝，不但無法管理，也很沒有效率；開發者可以透過專案中的 package.json，羅列出專案需要哪些套件，之後安裝時只需要 npm install，npm 便會自動依照 package.json 的內容下載套件。

版本控制

由於套件本身也是由開發者撰寫，也需要持續的更新迭代，公開出來的套件往往不會只有一個版本，套件管理工具自然也要能紀錄並提供各版本的套件供開發者使用；在 npm 的設計中，要求套件開發者透過 Semantic Versioning 的規範來定義套件版本：

• 主版號：當你做了 不相容 的 API 修改
• 次版號：當你做了向下相容的 功能性新增
• 修訂號：當你做了向下相容的 問題修正

而使用套件的開發者，則需透過指定的字元，在 package.json 中設定專案欲使用的套件版本，例如下列的例子：

"dendencies": {
    "accepts": "~1.3.7",
    "array-flatten": "1.1.1",
    "body-parser": "^1.19.0",
    // ...
  }

• 1.1.1：指定為 1.1.1 的版本
• ~1.3.7：指定為 >= 1.3.7 且 < 1.4.0 的版本