اگر چند سالی است با اکوسیستم JavaScript کار می کنید، احتمالاً تقریباً تمام پروژه هایتان را با npm مدیریت کرده اید. نصب پکیج ها، اجرای اسکریپت ها و حتی ساخت پروژه های جدید، همه با npm انجام می شد.

اما اگر اخیراً سراغ ابزارهایی مثل Nx، Turborepo یا پروژه های Monorepo رفته باشید، احتمالاً یک نام جدید بیشتر از قبل به چشمتان خورده است: pnpm.

شاید اولین سؤال این باشد که مگر npm چه مشکلی دارد که پروژه های جدید یکی یکی به سمت pnpm می روند؟

در این مقاله می خواهیم دقیقاً به همین سؤال پاسخ دهیم.

pnpm چیست؟

pnpm نیز مانند npm و Yarn یک Package Manager برای اکوسیستم Node.js است.

وظیفه آن دقیقاً همان کاری است که از یک Package Manager انتظار دارید:

نصب وابستگی ها
مدیریت نسخه ها
اجرای Scriptها
مدیریت Workspaceها

پس از نظر امکانات پایه، تفاوت زیادی با npm ندارد.

اما تفاوت اصلی در روش نگهداری و مدیریت وابستگی ها است؛ جایی که pnpm عملکرد کاملاً متفاوتی دارد.

مشکل npm از کجا شروع می شود؟

فرض کنید روی سیستم خود سه پروژه مختلف دارید.

هر سه پروژه از React، Axios و Lodash استفاده می کنند.

در npm، هر پروژه نسخه مخصوص به خودش از این پکیج ها را داخل پوشه node_modules نصب می کند.

project-a
└── node_modules
    ├── react
    ├── axios
    └── lodash

project-b
└── node_modules
    ├── react
    ├── axios
    └── lodash

project-c
└── node_modules
    ├── react
    ├── axios
    └── lodash

در نتیجه:

فضای دیسک بیشتری مصرف می شود.
نصب پروژه ها زمان بیشتری می برد.
وابستگی های تکراری بارها دانلود می شوند.

هرچند npm در نسخه های جدید کش بهتری دارد، اما همچنان ساختار node_modules باعث ایجاد حجم زیادی از فایل های تکراری می شود.

pnpm این مشکل را چگونه حل می کند؟

ایده pnpm بسیار ساده است.

به جای اینکه هر پروژه نسخه جداگانه ای از هر پکیج داشته باشد، pnpm همه پکیج ها را فقط یک بار در یک فضای مشترک روی سیستم ذخیره می کند.

Global Store

react@19.1.0
axios@1.11.0
lodash@4.17.21

سپس داخل هر پروژه، به جای کپی کردن فایل ها، تنها لینک هایی به این نسخه ها ایجاد می کند.

project
└── node_modules
      react  -> Global Store
      axios  -> Global Store
      lodash -> Global Store

به همین دلیل:

حجم مصرفی دیسک به شکل محسوسی کاهش پیدا می کند.
نصب پروژه ها سریع تر می شود.
دانلودهای تکراری تقریباً از بین می روند.

چرا pnpm سریع تر است؟

یکی از دلایل اصلی محبوبیت pnpm سرعت بالای آن است.

این سرعت فقط به خاطر Cache نیست؛ بلکه نتیجه چند تکنیک مختلف است:

ذخیره تنها یک نسخه از هر پکیج
استفاده از Hard Link و Symbolic Link
دانلود نکردن مجدد پکیج های موجود
ساختار بهینه تر node_modules

در پروژه های کوچک شاید این تفاوت چندان محسوس نباشد، اما در پروژه های بزرگ یا Monorepo می تواند زمان نصب وابستگی ها را به شکل قابل توجهی کاهش دهد.

معماری متفاوت node_modules

یکی از ویژگی های جالب pnpm این است که اجازه نمی دهد پروژه به صورت تصادفی از وابستگی هایی استفاده کند که مستقیماً نصب نشده اند.

فرض کنید پکیج A از پکیج B استفاده می کند.

اگر پروژه شما B را مستقیماً نصب نکرده باشد، در npm ممکن است همچنان بتوانید آن را import کنید؛ چون ساختار سنتی node_modules این اجازه را می دهد.

این رفتار که به آن Phantom Dependency می گویند، می تواند باعث شود پروژه روی سیستم شما بدون مشکل اجرا شود، اما روی سیستم همکار یا محیط CI با خطا مواجه شود.

pnpm با ساختار لینک شده ی خود جلوی این اتفاق را می گیرد و فقط وابستگی هایی را در دسترس قرار می دهد که واقعاً در package.json تعریف شده اند.

این موضوع باعث می شود وابستگی های پروژه شفاف تر، قابل پیش بینی تر و قابل اعتمادتر باشند.

چرا pnpm برای Monorepo انتخاب محبوبی است؟

در معماری Monorepo معمولاً چندین پروژه کنار هم قرار می گیرند.

برای مثال:

apps
├── admin
├── api
└── website

packages
├── ui
├── utils
└── config

اگر هر Workspace وابستگی های خودش را دوباره نصب کند، حجم پروژه به سرعت افزایش پیدا می کند.

اما pnpm تمام Workspaceها را از طریق یک Store مشترک مدیریت می کند.

این یعنی:

فضای دیسک کمتر
نصب سریع تر
مدیریت نسخه ها ساده تر
هماهنگی بیشتر بین پروژه ها

به همین دلیل بسیاری از ابزارهای مدرن مانند Nx، Turborepo و بسیاری از پروژه های متن باز، pnpm را به عنوان گزینه پیش فرض یا پیشنهادی معرفی می کنند.

مزایای pnpm

نصب سریع تر، مخصوصاً بعد از اولین نصب
مصرف بسیار کمتر فضای دیسک
ساختار بهینه برای Monorepo
جلوگیری از Phantom Dependency
Workspaceهای قدرتمند
مدیریت بهتر وابستگی ها
سازگاری با بیشتر پروژه های مبتنی بر npm

معایب pnpm

البته pnpm هم بدون ایراد نیست.

برخی پکیج های قدیمی ممکن است با ساختار لینک شده آن سازگار نباشند.
اگر ابزاری به ساختار سنتی node_modules وابسته باشد، ممکن است نیاز به تنظیمات اضافی داشته باشد.
برای تیم هایی که سال ها فقط با npm کار کرده اند، آشنایی با چند مفهوم جدید زمان می برد.
برخی آموزش ها و مستندات قدیمی هنوز فقط دستورات npm را پوشش می دهند.

با این حال، این مشکلات روزبه روز کمتر می شوند و اکوسیستم Node.js سازگاری بسیار بهتری با pnpm پیدا کرده است.

مقایسه npm و pnpm

ویژگی	npm	pnpm
سرعت نصب	خوب	بسیار خوب
مصرف فضای دیسک	زیاد	کم
مدیریت Workspace	خوب	بسیار خوب
مناسب Monorepo	خوب	عالی
جلوگیری از Phantom Dependency	خیر	بله
سازگاری با اکوسیستم	بسیار بالا	بسیار بالا

آیا باید به pnpm مهاجرت کنیم؟

اگر روی پروژه های شخصی کوچک کار می کنید، npm همچنان انتخاب مناسبی است و احتمالاً نیازی به مهاجرت فوری ندارید.

اما اگر روی پروژه های بزرگ، تیمی یا Monorepo فعالیت می کنید، pnpm می تواند مزایای قابل توجهی از نظر سرعت، مدیریت وابستگی ها و مصرف فضای دیسک در اختیار شما قرار دهد.

به همین دلیل است که در سال های اخیر، بسیاری از پروژه های مدرن و ابزارهای توسعه، pnpm را به عنوان انتخاب اصلی یا پیشنهادی خود معرفی می کنند.

در نهایت، مهم ترین تفاوت pnpm با npm فقط چند دستور جدید نیست؛ بلکه فلسفه متفاوتی در مدیریت وابستگی هاست. همین تفاوت باعث شده pnpm به یکی از محبوب ترین Package Managerهای اکوسیستم Node.js تبدیل شود و به نظر می رسد این روند همچنان ادامه خواهد داشت.

pnpm چیست و چرا پروژه‌های جدید به سمت آن مهاجرت می‌کنند؟

علی صفری

نظرات