درون تغییرات pnpm ۱۲؛ جایگزینی هسته برای بهینه‌سازی حافظه

اگر در پروژه‌های بزرگ با مشکل کندی نصب پکیج‌ها یا اشغال بیش از حد رم مواجه هستید، pnpm 12 دقیقاً برای حل همین نقاط درد طراحی شده است. این نسخه با یک بازنویسی بنیادین، سرعت عملیات را به سطحی رسانده که انتظار آن را نداشتید.

طبق اعلام تیم توسعه، pnpm 12 اکنون با زبان Rust بازنویسی شده است تا جهشی عظیم در عملکرد داشته باشد، بدون آنکه کاربران مجبور به تغییر پیکربندی‌های فعلی خود شوند. تمام دستورات، فلگ‌ها و فرمت‌های lockfile از نسخه ۱۱ به‌طور کامل به این نسخه منتقل شده‌اند.

اکوسیستم جاوااسکریپت سال‌هاست با سربار مدیریت وابستگی‌ها دست‌وپنجه نرم می‌کند. مدیریت پکیج‌ها اغلب با تورم حافظه و زمان‌های طولانی برای تحلیل وابستگی‌ها — به‌ویژه در مونو-ریپوهای (monorepos) عظیم — می‌جنگند. pnpm با انتقال منطق هسته به Rust، قصد دارد این گلوگاه‌ها را حذف کند در حالی که تجربه کاربری را دقیقاً مشابه نسخه‌های قبلی نگه دارد.

همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی ابزارهای توسعه اشاره کردیم، گرایش به زبان‌های سیستمی برای جایگزینی ابزارهای Node.js یک روند تثبیت‌شده است.

نصب و سازگاری

به دلیل اینکه تگ latest در npm هنوز به خط pnpm 11 اشاره می‌کند، نسخه ۱۲ باید از تگ next-12 نصب شود. برای کاربرانی که Node.js ندارند، روش‌های نصب دیگری وجود دارد، هرچند ابزارهایی مثل Homebrew یا Chocolatey هنوز این نسخه را ارائه نداده‌اند.

عملکرد و منطق Lockfile

یکی از مهم‌ترین تغییرات فنی، نحوه مدیریت گراف‌های وابستگی چرخشی (cyclic dependency graphs) است. در نسخه ۱۲، چرخه‌های وابستگی در طول فرآیند استنتاج (Inference) — که مثل لحظه آشپزی واقعی است، نه دوره‌ی آموزش آشپز — به‌صورت استاندارد شکسته می‌شوند. اعضای هر چرخه بر اساس ID پکیج مرتب شده و لبه‌هایی که چرخه را می‌بندند، همیشه در یک نقطه قطع می‌شوند.

این تغییر تضمین می‌کند که lockfile یک تابع خالص از گراف وابستگی باشد. بر اساس گزارش pnpm.io، این تغییر مزایای عملی فوری برای محیط‌های کاری بزرگ دارد:

• سرعت استنتاج Peer Resolution اکنون ۲ تا ۳ برابر بیشتر شده است.
• مصرف حافظه تقریباً ۲۵٪ کاهش یافته است.
• حجم فایل‌های lockfile به‌طور قابل‌توجهی کمتر شده است.

بهینه‌سازی‌های ذخیره‌سازی در لینوکس

در لینوکس، متد packageImportMethod: auto اکنون اولویت را به hardlinks نسبت به reflinks می‌دهد. در سیستم‌فایل btrfs، این تغییر زمان ایجاد node_modules از یک استور گرم را تقریباً نصف می‌کند.

• ext4: تغییری نکرده است چون از cloning پشتیبانی نمی‌کرد.
• macOS: همچنان اولویت با clone است، زیرا clonefile در APFS یک ابزار ارزان و سریع است.
• لینوکس: اگر hardlink پذیرفته نشود، سیستم به سراغ clone می‌رود.

باینری‌های سراسری آگاه از پروژه

pnpm 12 یک سیستم شیم (shim) پیشرفته برای باینری‌های سراسری معرفی کرده است. اگر Node.js، Deno یا Bun را به‌صورت سراسری نصب کرده‌اید، ابزار اکنون به‌جای پیش‌فرض سراسری، از نسخه‌ای که در پروژه فعلی شما پین شده است پیروی می‌کند.

این اتفاق بدون نیاز به قلاب‌های شل (shell hooks) رخ می‌دهد و توسط تنظیمات globalShims کنترل می‌شود. برای امنیت، ابزار اعتماد را بر اساس منبع مدیریت می‌کند؛ برای مثال، نسخه‌های پایدار Node.js با امضای تیم انتشار تایید می‌شوند، اما برای Deno یا Bun، یک‌بار از کاربر پرسیده می‌شود: «آیا به این پروژه اعتماد دارید؟»

تامین مدیریت پکیج‌های یکپارچه

در حرکتی به سوی ارکستراسیون کامل اکوسیستم، pnpm اکنون می‌تواند سایر مدیریت پکیج‌ها را تامین کند. این ابزار می‌تواند npm، Yarn Classic، Yarn Berry و Bun را از طریق ریجستری‌های مورد اعتماد دریافت و تایید کند.

این قابلیت سه گردش‌کار کلیدی را ممکن می‌کند:
۱. وابستگی‌های میزبانی‌شده در Git: این‌ها با همان مدیریت پکیجی آماده می‌شوند که درخواست کرده‌اند. مثلاً مخزنی که با Yarn ساخته شده، اکنون روی سیستمی که فقط pnpm دارد، نصب می‌شود.
۲. دستورات یک‌باره: دستور pnx می‌تواند نسخه‌های خاصی را اجرا کند، مثل pnx yarn@4 install.
۳. شیم‌های پین‌شده: دستور pnpm shim add yarn نسخه‌ای از Yarn را لینک می‌کند که هر چه پروژه پین کرده باشد را اجرا کند.

بازبینی‌های ریجستری و امنیت

برای حل مشکل وصله کردن آسیب‌پذیری‌ها بدون تغییر شماره نسخه، pnpm 12 قابلیت بازبینی ریجستری (Registry Revisions) را معرفی کرده است. یک ریجستری اکنون می‌تواند یک آرتیفکت جایگزین برای یک نسخه موجود ارائه دهد — مثلاً نسخه‌ای که یک باگ امنیتی در آن رفع شده — بدون اینکه شماره نسخه یا URL تغییر کند.

این بازبینی‌ها با استفاده از یک هضم (digest) کامل SHA-512 شناسایی و در lockfile ثبت می‌شوند. این یعنی فایل‌های lockfile که جایگزین‌ها را نپذیرفته‌اند، با نسخه‌های قبلی کاملاً یکسان می‌مانند. این رویکرد برای تضمین یکپارچگی نسخه‌ها مشابه است با آنچه در استفاده از Commit Hash برای جلوگیری از تغییرات خاموش در مدل‌های Llama مشاهده می‌کنیم تا از هرگونه تغییر ناخواسته در محیط‌های عملیاتی جلوگیری شود.

اصلاحات تجربه توسعه‌دهنده

چندین بهبود در کیفیت زندگی (QoL) برای کاهش اصطکاک‌ها اعمال شده است:

• تنظیمات Workspace: غلط‌های املایی در pnpm-workspace.yaml دیگر نادیده گرفته نمی‌شوند و pnpm نام درست را پیشنهاد می‌دهد.
• حفاظت Sudo: دستورات سراسری مثل pnpm setup در حالت sudo با خطای ERR_PNPM_SUDO_NOT_SUPPORTED متوقف می‌شوند تا از تغییرات ناخواسته در دایرکتوری root جلوگیری شود.
• پشتیبانی از Sandbox هوش مصنوعی: در محیط‌هایی که hard link پذیرفته نمی‌شود (مثل کانتینرهای محدود)، pnpm یک استور محلی در <project>/node_modules/.pnpm-store ایجاد می‌کند.
• سخت‌گیری در Engine: در حالت engineStrict، اگر پکیجی ناسازگار در هر جای درخت وابستگی باشد، نصب با خطا مواجه می‌شود.

ویژگی‌های تجربی

به عنوان یک اثبات مفهوم (PoC)، pnpm 12 یک کش اثرات جانبی از راه دور (remote side-effects cache) را شامل می‌شود. این قابلیت به تیم‌ها اجازه می‌دهد خروجی‌های Build را بین ماشین‌های مختلف به اشتراک بگذارند تا نیازی به اجرای مجدد اسکریپت‌های lifecycle در هر ماشین نباشد. این ویژگی فعلاً محدود به معماری‌های x64 و arm64 لینوکس است.

گام بعدی شما

• اگر در پروژه‌های بزرگ هستید، با دستور npm add -g pnpm@next-12 سرعت نصب را تست کنید.
• تنظیمات globalShims را بررسی کنید تا از تداخل نسخه‌های سراسری Node.js و نسخه‌های پروژه جلوگیری کنید.
• در صورت استفاده از لینوکس، متد packageImportMethod را برای بهینه‌سازی فضای دیسک بررسی کنید.

اما داستان سخت‌افزاری این تحول و تاثیر زبان Rust بر ابزارهای توسعه حتی شگفت‌انگیزتر است — به تحلیل ما درباره جایگزینی ابزارهای JS با Rust مراجعه کنید.