وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع خطای npm ci در هاست Node.js؛ وقتی package-lock با پروژه هماهنگ نیست

راهنمای عملی رفع ناسازگاری package.json و package-lock.json، تفاوت npm ci و npm install و استقرار ایمن برنامه Node.js روی هاست.

انتشار:
توسط تیم فنی نت‌آرام
۷ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع خطای npm ci در هاست Node.js؛ وقتی package-lock با پروژه هماهنگ نیست در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
هنگام انتقال برنامه Node.js، نصب بسته‌ها با npm ci متوقف می‌شود و پیامی شبیه «package.json and package-lock.json are not in sync» می‌بینید. برنامه روی لپ‌تاپ کار می‌کند، اما هاست به مرحله اجرا نمی‌رسد. این پیام معمولاً یعنی فهرست نیازهای پروژه با نسخه‌های ثبت‌شده در فایل قفل هم‌خوان نیست، یا نسخه و تنظیمات ابزار نصب در دو محیط فرق دارد.
در ادامه دلیل توقف را پیدا می‌کنیم، فایل درست را در یک نسخه آزمایشی هماهنگ می‌کنیم و بعد برنامه را با امکان بازگشت به هاست منتقل می‌کنیم. اگر خطای شما شبکه، کمبود حافظه یا مجوز است، مراحل تشخیص آن را هم می‌خوانید؛ هر شکست نصب به معنی خراب بودن فایل قفل نیست.

npm ci چه تفاوتی با npm install دارد؟

فایل package.json نام بسته‌ها و محدوده نسخه‌های قابل قبول را نگه می‌دارد. فایل package-lock.json نتیجه دقیق‌تر انتخاب نسخه‌ها و درخت وابستگی را ثبت می‌کند. npm ci برای نصب تکرارپذیر طراحی شده است: به فایل قفل نیاز دارد و در صورت ناسازگاری آن با فایل اصلی متوقف می‌شود؛ خودش فایل‌ها را برایتان هماهنگ نمی‌کند.
نکته مهم: این فرمان پیش از نصب، پوشه موجود node_modules را پاک می‌کند. بنابراین آن را روی برنامه فعال و تنها نسخه سالم اجرا نکنید. روی بعضی هاست‌های مبتنی بر Node.js Selector، این مسیر به محیط مدیریت‌شده برنامه متصل است؛ جابه‌جایی یا حذف دستی آن ممکن است اجرای برنامه را قطع کند. اگر از سازوکار محیط و روش مجاز نصب مطمئن نیستید، اول در پنل و راهنمای ارائه‌دهنده روش همان سرویس را ببینید.

۱. متن واقعی خطا و محیط نصب را مشخص کنید

در cPanel بخش Setup Node.js App را باز کنید و نسخه Node.js، مسیر Application root و نام فایل شروع برنامه را یادداشت کنید. اگر در آن صفحه فرمان ورود به محیط برنامه وجود دارد، آن را عیناً در Terminal یا SSH حساب اجرا کنید. نسخه‌های موجود و دسترسی Terminal به تنظیم سرویس بستگی دارند.
داخل پوشه پروژه، این فرمان‌ها را اجرا کنید. ~/my-node-app نمونه است؛ مسیر واقعی را از پنل بردارید:
کد / دستورcd ~/my-node-app pwd node --version npm --version ls -la package.json package-lock.json
چهار خط اول مسیر و نسخه‌های ابزار را نشان می‌دهند؛ خط آخر می‌گوید دو فایل اصلی در همین پوشه هستند یا نه. اگر پیام نبودن package-lock.json دیدید، نخست در نسخه اصلی پروژه یا مخزن Git دنبال آن بگردید. با آپلود ناقص یا اجرای فرمان در پوشه اشتباه هم همین اتفاق می‌افتد. اگر پروژه عمداً از ابزار دیگری مثل Yarn استفاده می‌کند، بدون هماهنگی آن را به npm تغییر ندهید.
متن خطا را بخوانید. عبارت «not in sync» یا اشاره به بسته‌ای که در فایل قفل نیست به این راهنما مربوط است. EACCES بیشتر به دسترسی فایل، ENOSPC به فضا یا سهمیه، ENOMEM به حافظه و ETIMEDOUT به اتصال اشاره می‌کند. برای هرکدام مسیر متفاوت است؛ تغییر فایل قفل به‌تنهایی آن‌ها را رفع نمی‌کند.

۲. نسخه آزمایشی و امکان بازگشت داشته باشید

روی رایانه توسعه یا در پوشه آزمایشی مجزا که به برنامه زنده وصل نیست، از همان نسخه پروژه استفاده کنید. اگر پروژه از Git استفاده می‌کند، این دستورها در ترمینال همان نسخه آزمایشی وضعیت را نشان می‌دهند:
کد / دستورgit status --short git log -1 --oneline git diff -- package.json package-lock.json
خروجی git status فایل‌های تغییرکرده را نشان می‌دهد؛ خروجی دستور سوم تفاوت دو فایل را نسبت به آخرین ثبت نشان می‌دهد. اگر فایل‌ها تغییر دارند و علتشان را نمی‌دانید، قبل از ادامه از آن‌ها نسخه بگیرید و با فرد مسئول پروژه هماهنگ شوید. یکسان بودن خروجی لاگ دو محیط به‌تنهایی ثابت نمی‌کند متغیرهای محیطی و فایل‌های آپلودنشده هم یکسان‌اند.
اگر از Git استفاده نمی‌کنید، دو فایل را از پروژه اصلی با نسخه روی هاست مقایسه کنید. مراقب باشید فایل .env، رمزها و داده مشتری را همراه نمونه آزمایشی در محل عمومی قرار ندهید. اگر فایل قفل در پروژه اصلی موجود است ولی در هاست نیست، ابتدا همان فایل درست را انتقال دهید؛ تولید فایل تازه همیشه لازم نیست.

۳. علت ناسازگاری را برطرف کنید

مثلاً ممکن است توسعه‌دهنده بسته‌ای را به package.json اضافه کرده ولی فایل قفل به مخزن یا هاست نرسیده باشد. در نسخه آزمایشی و با نسخه Node.js و npm سازگار با پروژه، دستور زیر را اجرا کنید:
کد / دستورnpm install
این دستور بسته‌ها را نصب می‌کند و در صورت نیاز فایل قفل را تغییر می‌دهد. چون می‌تواند نسخه‌های جدیدی را در محدوده مجاز انتخاب کند و اسکریپت‌های نصب بسته‌ها را اجرا کند، فقط برای پروژه و وابستگی‌های مورد اعتماد و با دسترسی لازم انجامش دهید. پس از آن، تغییرات را ببینید:
کد / دستورgit diff -- package.json package-lock.json npm ls --depth=0
فرمان اول نشان می‌دهد چه چیزی تغییر کرده است؛ دوم وابستگی‌های مستقیم نصب‌شده را نشان می‌دهد و در صورت مشکل ممکن است خودش هم خطا بدهد. سپس آزمایش‌های موجود پروژه را طبق دستورهای واقعی همان پروژه اجرا کنید. برای نمونه، اگر واقعاً اسکریپت‌های test و build در package.json تعریف شده‌اند:
کد / دستورnpm test npm run build
موفقیت این دو فرمان به اسکریپت‌های پروژه بستگی دارد. اگر وجود ندارند، نام اسکریپت را از بخش scripts پروژه بردارید و اجرای دستورات ساختگی را جایگزین آزمایش نکنید. وقتی تغییرات تأیید شد، package.json و package-lock.json هماهنگ را با هم ثبت و منتقل کنید؛ نه اینکه فقط یکی را آپلود کنید.

۴. نصب مجدد را در محیط آزمایشی امتحان کنید

پس از اطمینان از اینکه در کپی آزمایشی هستید و به برنامه زنده آسیبی نمی‌رسد، دستور زیر نصب از روی فایل قفل را امتحان می‌کند:
کد / دستورnpm ci
اگر فرمان بدون خطا پایان یافت، دوباره تست و ساخت پروژه را اجرا کنید. این موفقیت نشان می‌دهد در آن محیط مشخص فایل‌ها با هم قابل نصب‌اند؛ تضمین نمی‌کند نسخه Node.js، متغیرها یا بسته‌های سیستمی هاست نیز همان باشند. اگر در نسخه اصلی فایل قفل با گزینه‌هایی مانند --legacy-peer-deps ساخته شده، طبق مستندات npm باید همان تنظیم سازگار در محیط نصب موجود باشد. این گزینه را برای ساکت‌کردن هر خطایی کورکورانه اضافه نکنید؛ ابتدا دلیل وابستگی‌های ناسازگار را با توسعه‌دهنده بررسی کنید.
در هاست، نسخه تأییدشده را به روش انتشار برنامه خود منتقل کنید. در صفحه مدیریت برنامه، عملیات نصب وابستگی را با روش پشتیبانی‌شده پنل انجام دهید؛ نام دکمه و اینکه npm install یا فرمان دیگری اجرا می‌شود ممکن است متفاوت باشد. بعد برنامه را از همان پنل Restart کنید. نسخه قبلی کد و تنظیمات لازم برای بازگشت را تا تأیید نتیجه نگه دارید.

اگر باز هم نصب یا اجرا شکست خورد

اگر پیام همچنان ناسازگاری را نشان می‌دهد، دوباره مسیر پروژه و نسخه واقعی فایل‌های منتقل‌شده را مقایسه کنید؛ گاهی پوشه دیگری منتشر شده یا فایل قفل در فرآیند انتقال جا مانده است. اگر خطا به بسته‌ای در devDependencies مربوط است، در نظر بگیرید محیط Production ممکن است نصب آن‌ها را حذف کند. ابزارهای لازم برای ساخت باید در مرحله ساخت موجود باشند و وابستگی‌های لازم در زمان اجرا باید جای درست تعریف شوند؛ جابه‌جایی بی‌دلیل همه بسته‌ها بهترین راه‌حل نیست.
اگر خطای شبکه یا کمبود فضا می‌بینید، همان متن را جداگانه دنبال کنید. برای بررسی سریع فضای قابل مشاهده حساب و وجود بسته نصب‌شده می‌توانید بنویسید:
کد / دستورdf -h . npm ls --depth=0
خروجی فضای سیستم فایل الزاماً سهمیه حساب شما را نشان نمی‌دهد؛ میزان سهمیه را نیز در پنل ببینید. از خاموش‌کردن بررسی TLS یا اجرای فرمان‌های پاک‌سازی سراسری برای ردشدن از خطا خودداری کنید. در پایان، صفحه یا API واقعی و گزارش برنامه را امتحان کنید؛ موفقیت نصب به معنی موفقیت اجرای برنامه نیست.
برای بررسی امکانات مناسب پروژه، صفحه هاست Node.js نت‌آرام و راهنمای انتخاب بین هاست Node.js و سرور مجازی را ببینید. رفتار دقیق دستور در مستندات رسمی npm ci توضیح داده شده است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام