使用pnpm包管理器替代npm及yarn的命令範例

前言

今天給大家介紹一種新的包管理器：pnpm，pnpm 由 zkochan 開發，最初也是在用 npm 或者 yarn 遇到了一些不爽的地方，於是自己做了一個開源的包管理器，也為優化包管理提供了一種不同的新思路，接下來我們就看一下為何要使用 pnpm，以及他能做什麼

值得一提的是，zkochan 也是一名烏克蘭的開發者，他也在主頁呼籲大家援助一下烏克蘭，我也希望當前的國際局勢能更快的穩定下來，不要損失這麼優秀的開發者

為什麼會有 pnpm

一句話概括就是：節約磁碟空間並提升安裝速度

設想一下，假如公司的每個專案都用了 vue 全家桶，那麼每個專案都需要安裝 vue、vue-router、vuex、axios 等幾乎相同的庫，如果有 100 個專案，那就要重複安裝 100 遍！！，要知道，現如今，硬碟雖然便宜，但也沒那麼多插槽啊，更別說筆記型電腦這寸土寸金的資源空間。

因此，pnpm 的核心就是將所有的包都存放在一個資源倉庫中，而每個專案的 node_modules 通過軟連結的形式將包連結到資源倉庫中，這樣不僅節省了空間，同時也加快了安裝速度

不止於此

pnpm 的另一個優點，在保留了非扁平化的 node_modules 資料夾，同時節省了空間

什麼是扁平化的 node_modules

我們簡單回顧一下 npm 的發展歷史

1.最初，npm 只是簡單的通過依賴去遞迴的安裝包，所有的依賴放在相應的包資料夾下面，假如 A 依賴了 foo，B 也依賴了 foo，那麼就會有兩份 foo 安裝在 node_modules

node_modules
├── A
│   └── node_modules
│       └── foo
└── B
    └── node_modules
        └── foo

2.經過一次優化， npm 為了節省空間，採用了扁平化的 node_modules，這樣，假如 A 和 B 都依賴了 foo，那麼 foo 會提升至頂層，也就是說 node_modules 資料夾裡的包會變成 A、B、foo

node_modules
├── A
├── B  
└── foo

這樣的好處是，同一個包 foo 只會有一份，節省了空間，但是引入了一個新的問題，參照混亂！！。

試想一下，我們的專案依賴本來只有 A 和 B，假如你想 import foo，肯定是找不到的，但是扁平化的結果，將 A 和 B 的依賴層級提升到了頂級，這樣，我們直接參照 foo，其實也不會報錯，但實際上我們並沒有指定依賴 foo，導致了使用上的混亂，假如有一天，A 和 B 都不依賴於 foo 了，那我們的專案或者說我提供的包就會報錯

這個不良的行為其實已經默默的融入我們的開發中，當我們使用 ant-design 時，我們可以直接使用 moment，當我們使用 axios 時，我們可以直接使用 qs，當我們使用 webpack 時，我們可以直接使用 lodash，而無需額外的安裝包

pnpm 的 node_modules

假設我們的專案依賴 foo 包，而 foo 又依賴 bar 包，那麼 pnpm 安裝後的實際 node_modules 結果如下

node_modules
├── foo -> ./.pnpm/foo@1.0.0/node_modules/foo
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       └── bar -> <store>/bar
    └── foo@1.0.0
        └── node_modules
            ├── foo -> <store>/foo
            └── bar -> ../../bar@1.0.0/node_modules/bar

我們分析一下這個目錄結構

• 包都是從 store 軟連結而來
• 專案直接使用的包只有一個 foo，保證了只有依賴項中的包才能存取
• 有個隱藏的資料夾 .pnpm，這裡將所有的依賴進行扁平化，這樣避免了迴圈符號連結，同時 foo 還能參照自己

如果新增 qar@2.0.0 作為 bar 和 foo 的依賴項，那麼結果會變成

node_modules
├── foo -> ./.pnpm/foo@1.0.0/node_modules/foo
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       ├── bar -> <store>/bar
    │       └── qar -> ../../qar@2.0.0/node_modules/qar
    ├── foo@1.0.0
    │   └── node_modules
    │       ├── foo -> <store>/foo
    │       ├── bar -> ../../bar@1.0.0/node_modules/bar
    │       └── qar -> ../../qar@2.0.0/node_modules/qar
    └── qar@2.0.0
        └── node_modules
            └── qar -> <store>/qar

如何使用 pnpm

安裝

直接安裝

curl -fsSL https://get.pnpm.io/install.sh | PNPM_VERSION=7.0.0-rc.2 sh -

或者

wget -qO- https://get.pnpm.io/install.sh | PNPM_VERSION=7.0.0-rc.2 sh -

通過 npm 安裝

npm install -g pnpm@next-7

通過 HomeBrew 安裝（ 一種 MacOS 包管理器）

brew install pnpm

升級

簡單的通過 pnpm 自己的命令升級即可

pnpm add -g pnpm

使用

設定

大部分設定可以直接使用 npm 的設定，與之區別的是有些設定可能是 pnpm 專有的，例如：

# 設定倉庫路徑
pnpm config set store-dir /path/to/.pnpm-store

命令

安裝依賴

pnpm install
# 其他一些引數
--offline   僅從 store 中離線下載
--dev, -D   只下載 devDependencies 依賴
--frozen-lockfile  不會生成 lockfile
--shamefully-hoist 建立扁平結構，類似於 npm ，不推薦

2. 增加依賴

pnpm add <pkg>

這裡 pnpm 有多種增加方式

• 直接通過設定的源安裝

在 workspace 中，會先檢查 workspace 是否有相應包，至於 workspace 是什麼，在下面會詳細說道

從本地安裝: 例如你想偵錯開發的包時

pnpm add ./package.tar.gz
pnpm add ./some-directory

從遠端安裝 Tar 包

pnpm add https://github.com/indexzero/forever/tarball/v0.5.6

從 git 安裝

pnpm add <git remote url>

# 其他一些引數
--save-dev, -D	安裝為 devDependencies，也就是開發環境使用的包
--save-peer  	安裝為 peerDependencies ，同時安裝到 devDependencies， peerDependencies 通常是和該包一起使用的其他包，需要使用者同時下載
--global, -g	安裝為全域性依賴

釋出依賴

pnpm [-r] publish [<tarball|folder>] [--tag <tag>]
     [--access <public|restricted>] [options]
--no-git-checks	不檢查當前分支是否是可釋出分支，是否有沒有提交的程式碼，直接釋出
--dry-run	執行釋出包的所有流程，但唯獨不會真正把包釋出到源上，這個在測試釋出的時候非常有用
-r		遞迴的執行釋出命令，通常在 workspace 中使用

這裡只列出常用的一些，更多的命令可以參考官網

和其他包管理器比較

Monorepo 及 工作空間（Workspace）

什麼是 Monorepo

Monorepo 由兩個單片語成，Mono 指的是單個（single），repo 指的是專案儲存（Repository），合起來意思就是說，大量的專案儲存在單一的庫中，用人話講就是，不同的專案都寫在一個 git 庫裡，第一次聽到這個概念的時候大家肯定覺得這人指定有什麼大病，這麼多專案放一起，大家在裡面各種修改，一個人專案修改了，另一個不相干的專案肯定還得更新程式碼，這不是技術倒退麼，這個其實還真就是 Monorepo 的缺點，但是靜下心來考慮，他的優點也還是很多的，例如：

• 不同專案之間，如果需要複用相同的元件或者方法，現在就可以很方便的參照了，同時，這些公用方法一旦修改了，其他專案的相應邏輯互動也都更新了，不同在擔心忘了安裝或者更新，同時也比單純的 複製黏貼 要更科學

這裡插一句，很多公司的專案說是獨立的，其實都是從已有的專案中各種複製來的，連帶著以前的 bug 也都有了，還不如放一起呢

• 也不是所有的專案都適合放在一起，只有專案之間重合度高的，才應該放一起，例如：管理系統，基本表單操作之類的複用度很高，如果是不相關的專案，彼此沒有交集，那就別折騰了
• 不同專案之間，如果拆分的力度比較細，互相之間有呼叫，那就適合放在一起，最常見的是 npm 庫，不同的庫之間可能有依賴，同時每個庫還需要單獨釋出
• 它倡導了一種開放，透明，共用的組織文化，所有的開發者都可以瀏覽學習其他人的程式碼

說完了 Monorepo ,離真正應用還是有點差距，多個專案之間需要保證自己的獨立性，還需要能方便的根據其他專案的變動做出相應的改變，目前市面上也有很多其他的方便管理 Monorepo 的工具，例如：lernajs，幸運的是，pnpm 也對 Monorepo 有著良好的支援，pnpm 稱他為 workspace

值得一提的是，vite 也對 Monorepo 做了支援，這使得當參照的其他庫發生變化時，正在使用 vite dev 開發的專案也會熱更新，詳細可見Monorepo 和連結依賴

Workspace

pnpm 可以建立一個 workspace 將多個專案合併到一箇中，一個 workspace 的根目錄下必須有 pnpm-workspace.yaml 檔案，常見的 pnpm-workspace.yaml 類似於下面這種設定，可以定義哪些檔案或者資料夾應該包含於 workspace 中

packages:
  # all packages in subdirs of packages/ and components/
  - 'packages/**'
  - 'components/**'
  # exclude packages that are inside test directories
  - '!**/test/**'

在 workspace 根目錄使用 pnpm install 命令時，會自動將 workspace 中的所有專案執行 pnpm install

workspace: 協定

pnpm 支援協定 workspace:，當使用這個協定時，pnpm 只會解析本地 workspace 中的包，workspace: 協定的使用方法和 package.json 參照包的方法一致

"foo": "workspace:*"
"foo": "workspace:../foo"
"foo": "workspace:~",
"foo": "workspace:^",
"zoo": "workspace:^1.5.0"

當需要釋出包時，例如使用 pnpm pack 或者 pnpm publish 命令時，將動態的把 workspace: 協定替換為真正的版本號

結語

pnpm 目前被越來越多的人使用，其中也包括 vue 這樣的一線開源框架，具體可以參見 使用範例

在諸如 pnpm 或者 yarn 這樣的開源專案影響下，npm 也在反思自己，也及時的做出了更新，例如：支援 workspace 等功能，希望這樣的良性迴圈也讓 js 社群越來越好，或許有一天我還會重投 npm 的懷抱也說不定

以上就是使用pnpm包管理器替代npm及yarn的命令範例的詳細內容，更多關於pnpm包管理器替代npm及yarn命令的資料請關注it145.com其它相關文章！