Pnpm không còn khuyến nghị sử dụng Corepack: Điều gì đã thay đổi?
Pnpm đã thay đổi khuyến nghị cài đặt và không còn ưu tiên Corepack như trước. Nguyên nhân chính đến từ lớp thực thi trung gian của Corepack, sự thay đổi kiến trúc của pnpm 12 và việc Corepack không còn được tích hợp mặc định trong các phiên bản Node.js mới. Bài viết này sẽ giải thích nguyên nhân và cách cài pnpm phù hợp cho môi trường development và CI/CD hiện nay.
Nội dung bài viết
Góc nhìn, kinh nghiệm và các ghi chú thực hành.
Pnpm đang thay đổi cách chúng ta cài package manager
Nếu đã sử dụng Node.js trong vài năm gần đây, có lẽ bạn từng gặp cách cài pnpm như sau:
Corepack từng là một giải pháp khá tiện lợi vì cho phép Node.js quản lý phiên bản của các package manager như pnpm hoặc Yarn.
Đặc biệt, chúng ta có thể khai báo phiên bản package manager ngay trong package.json:
{
"packageManager": "pnpm@11.15.0"
}
Nhờ đó, các thành viên trong dự án có thể sử dụng cùng một phiên bản pnpm, hạn chế những vấn đề do khác biệt môi trường development.
Tuy nhiên, trong năm 2026, pnpm bắt đầu thay đổi hướng đi này và không còn khuyến nghị Corepack làm phương thức cài đặt mặc định.
Corepack thực sự làm gì?
Khi cài pnpm thông qua Corepack, câu lệnh:
pnpm install
không nhất thiết gọi trực tiếp pnpm ngay lập tức.
Luồng thực thi trước đây có thể hiểu đơn giản như:
pnpm
↓
Node.js
↓
Corepack shim
↓
pnpm thực tế
Corepack đóng vai trò như một lớp trung gian.
Nó kiểm tra trường:
{
"packageManager": "pnpm@11.15.0"
}
sau đó tìm, tải và chạy đúng phiên bản pnpm mà project yêu cầu.
Cách tiếp cận này rất hữu ích về mặt quản lý version, nhưng đồng thời cũng tạo thêm một lớp JavaScript trước khi pnpm thực sự được chạy.
Trong benchmark được đề cập khi pnpm cập nhật tài liệu, pnpm 11.21.0 mất khoảng 264 ms khi chạy qua Corepack, trong khi chạy trực tiếp khoảng 237 ms. Chênh lệch này không quá đáng kể trong development thông thường, nhưng có thể trở nên đáng chú ý khi CI thực hiện nhiều lần gọi pnpm.
pnpm 12 thay đổi vấn đề như thế nào?
Đây mới là phần quan trọng nhất.
pnpm 12 đang được viết lại bằng Rust và chuyển dần sang dạng native executable, thay vì phụ thuộc hoàn toàn vào Node.js như các phiên bản trước.
Theo tài liệu pnpm hiện tại, pnpm 12 đang trong giai đoạn release candidate và có thể chạy dưới dạng native binary. Khi được cài bằng standalone installer, pnpm 12 thậm chí không cần Node.js để thực thi.
Điều này tạo ra một kiến trúc đơn giản hơn:
Trước đây
Terminal
↓
Node.js
↓
Corepack
↓
pnpm
Trong khi với native pnpm:
Terminal
↓
pnpm native binary
Việc thêm Corepack vào phía trước một executable native vì vậy không còn mang lại nhiều lợi ích như trước.
Corepack cũng gặp vấn đề với kiến trúc pnpm mới
Không chỉ liên quan đến performance.
pnpm 12 đã thay đổi cách package được đóng gói và phân phối.
Corepack vốn được thiết kế dựa trên cấu trúc của các JavaScript package manager truyền thống, trong khi pnpm 12 chuyển sang native binary. Điều này đã dẫn đến các trường hợp Corepack không thể xử lý pnpm 12 đúng cách và xuất hiện lỗi khi dùng các phiên bản pnpm mới.
Ví dụ đã có trường hợp:
corepack use pnpm@next-12
dẫn đến:
MODULE_NOT_FOUND
Do đó, đây không đơn thuần là câu chuyện tối ưu vài mili giây khởi động.
Kiến trúc của pnpm đang thay đổi theo hướng mà Corepack không còn là thành phần cần thiết trong chuỗi thực thi.
Node.js cũng đang dần rời xa Corepack
Một yếu tố khác là phía Node.js.
Corepack từng được phân phối cùng Node.js trong nhiều phiên bản, nhưng nó không còn được xem là thành phần mặc định lâu dài của Node.js.
Điều đó có thể tạo ra một quy trình khá vòng:
Node.js
↓
npm
↓
Corepack
↓
pnpm
Trong khi mục tiêu ban đầu của Corepack chính là giúp việc quản lý package manager trở nên đơn giản hơn.
Nếu phải dùng npm để cài Corepack, rồi dùng Corepack để cài pnpm, thì việc cài pnpm trực tiếp trở nên hợp lý hơn.
Vậy bây giờ nên cài pnpm như thế nào?
pnpm hiện cung cấp nhiều phương thức cài đặt trực tiếp.
Linux và macOS
Có thể sử dụng standalone installer:
curl -fsSL https://get.pnpm.io/install.sh | sh -
Hoặc sử dụng wget:
wget -qO- https://get.pnpm.io/install.sh | sh -
Standalone installer có một lợi thế khá thú vị: với pnpm native, chúng ta không nhất thiết phải có Node.js trước để chạy pnpm.
Nếu máy đã có Node.js
Một lựa chọn rất đơn giản là:
npx get-pnpm
Đây cũng là một trong những phương thức được tài liệu pnpm hiện tại hướng dẫn.
Với developer đã có Node.js trên máy, đây có lẽ là cách dễ nhớ nhất.
macOS với Homebrew
Nếu đang quản lý các developer tool bằng Homebrew:
brew install pnpm
Sau đó kiểm tra:
pnpm --version
Cách này đặc biệt phù hợp nếu bạn muốn Homebrew quản lý lifecycle của pnpm cùng các tool khác trên máy.
Còn Windows thì sao?
Trên Windows, pnpm cung cấp nhiều lựa chọn.
Có thể sử dụng:
npx get-pnpm
hoặc Winget:
winget install -e --id pnpm.pnpm
Ngoài ra còn có Scoop và Chocolatey.
Tài liệu hiện tại của pnpm lưu ý rằng Windows Defender đôi khi có thể ảnh hưởng đến executable được cài bằng standalone installer, vì vậy phương thức dựa trên npm hiện là một lựa chọn thuận tiện trên Windows.
Với môi trường development Windows của mình, mình sẽ ưu tiên:
npx get-pnpm
GitHub Actions thì sử dụng gì?
Đối với GitHub Actions, pnpm có action chính thức:
Điều này giúp môi trường local và CI/CD có thông tin rõ ràng hơn về package manager mà project sử dụng.
Project đang dùng Corepack có cần sửa ngay không?
Không nhất thiết.
Nếu một project hiện tại đang chạy ổn với:
corepack enable
và:
{
"packageManager": "pnpm@11.x.x"
}
thì không có lý do bắt buộc phải refactor pipeline ngay lập tức chỉ vì khuyến nghị mới.
Một chiến lược hợp lý hơn là:
Project cũ đang ổn → tiếp tục sử dụng.
Project mới → ưu tiên cách cài pnpm mới.
Khi nâng Node.js → xem xét bỏ Corepack.
Khi nâng major version pnpm → cập nhật pipeline.
Khi chuyển sang pnpm 12 → nên kiểm tra lại toàn bộ quy trình cài đặt.
Đây cũng là hướng tiếp cận khá hợp lý so với việc thay đổi một CI/CD pipeline đang hoạt động ổn chỉ để chạy theo một khuyến nghị mới.
Cách mình sẽ setup cho project mới
Nếu bắt đầu một project Next.js mới, mình sẽ không còn sử dụng:
corepack enable
Thay vào đó, trên máy development có Node.js:
npx get-pnpm
Sau đó:
pnpm --version
Khởi tạo project:
pnpm create next-app
và giữ version package manager trong package.json:
{
"packageManager": "pnpm@11.x.x"
}
Trên GitHub Actions:
- uses: pnpm/setup@v4
Cách setup này có ít thành phần trung gian hơn, dễ hiểu hơn và phù hợp hơn với hướng phát triển native của pnpm.
Kết luận
Việc pnpm không còn khuyến nghị Corepack không có nghĩa rằng Corepack là một công cụ tệ.
Trong nhiều năm, Corepack giải quyết khá tốt bài toán đồng bộ package manager giữa các môi trường development.
Nhưng hệ sinh thái đã thay đổi.
pnpm đang chuyển từ một CLI phụ thuộc Node.js sang một công cụ ngày càng mang tính native. Trong bối cảnh đó, việc phải khởi động thêm Node.js và chạy qua một Corepack shim trước khi đến pnpm trở nên ít cần thiết hơn.
Có thể tóm gọn sự thay đổi như sau:
Old approach
Node.js
↓
Corepack
↓
pnpm
New approach
pnpm
Đối với các project đang ổn định với pnpm 10 hoặc 11, không cần vội thay đổi.
Nhưng đối với project mới, CI/CD mới hoặc project đang chuẩn bị chuyển sang pnpm 12, đây là thời điểm phù hợp để loại Corepack khỏi default setup và sử dụng trực tiếp các phương thức cài đặt chính thức của pnpm
