محتوای آموزشی وبلاگ نت‌آرام
برنامه Node.js روی لپ‌تاپ درست اجرا می‌شود، اما بعد از انتقال به هاست، خطایی مثل
invalid ELF header یا NODE_MODULE_VERSION نشان می‌دهد. معمولاً این پیام درباره یک فایل .node است: بخشی از بسته که برای یک سیستم‌عامل، معماری پردازنده یا نسخه خاص محیط اجرا ساخته شده است. اگر پوشه node_modules ویندوز یا مک را به لینوکس منتقل کنید، فایل بومی ممکن است در مقصد قابل اجرا نباشد. تفاوت نسخه Node.js یا کتابخانه‌های سیستم هم علت‌های دیگری هستند.راه‌حل امن این نیست که فایل‌های برنامه فعال را فوراً پاک کنید. اول تشخیص می‌دهیم چه چیزی ناسازگار است، سپس یک نسخه جداگانه با همان نسخه Node.js هاست می‌سازیم و پیش از جایگزینی آن را آزمایش می‌کنیم.
۱. نام بسته و نوع خطا را از گزارش بردارید
گزارش اجرای برنامه را در پنل هاست یا ترمینال ببینید. مسیرهایی شبیه
node_modules/example/build/Release/addon.node معمولاً نام بسته مشکل‌دار را نشان می‌دهند. سه پیام متداول را از هم جدا کنید:invalid ELF header: فایل باینری ممکن است برای سیستم دیگری ساخته شده یا آسیب دیده باشد.NODE_MODULE_VERSION ... requires ...: ماژول از رابط بومی وابسته به نسخه متفاوتی از Node.js استفاده می‌کند.GLIBC_x.y not foundیا نام یک کتابخانه.so: فایل یا پیش‌نیاز آن با کتابخانه‌های محیط مقصد سازگار نیست.
این‌ها تشخیص اولیه‌اند، نه اثبات قطعی. برای مثال، همه افزونه‌ها از همان رابط وابسته به نسخه استفاده نمی‌کنند؛ برخی با Node-API ساخته می‌شوند و سازگاری متفاوتی دارند.
۲. محیط واقعی اجرا را با محیط نصب مقایسه کنید
در Terminal یا SSH حساب هاست، وارد پوشه آزمایشی پروژه شوید. مسیر نمونه را با مسیر خود عوض کنید:
کد / دستورcd ~/myapp-test
pwd
node --version
npm --version
node -p "process.platform + ' ' + process.arch"
node -p "process.versions.modules"
خروجی چهار دستور آخر، نسخه Node و npm، سیستم و معماری، و شماره رابط ماژول Node جاری را نشان می‌دهد. در پنل برنامه نیز نسخه انتخاب‌شده را ببینید؛ گاهی
node ترمینال با نسخه اجرای برنامه تفاوت دارد. اگر پنل فرمان ورود به محیط برنامه می‌دهد، همان را در ترمینال فعال کنید و دستورها را تکرار کنید. صرف دیدن نسخه ترمینال ثابت نمی‌کند وب‌سرور هم از آن استفاده می‌کند.اگر ابزار
کد / دستورfile در دسترس است، مسیر واقعی فایلی را که در خطا آمده به جای نمونه بگذارید:file node_modules/example/build/Release/addon.node
روی یک میزبان لینوکسی انتظار فایلی سازگار با معماری همان میزبان را دارید؛ مثلاً فایل ساخته‌شده برای Windows یا macOS نشانه انتقال نامناسب است. نبودن
file در هاست اشتراکی غیرعادی نیست و به مجوز مدیریتی برای نصب آن نیاز ندارید؛ متن خطا و مشخصات محیط را برای پشتیبانی بفرستید.۳. وابستگی‌ها را در پوشه آزمایشی و مقصد نصب کنید
از کد و فایل قفل نسخه سالم نسخه پشتیبان داشته باشید. یک کپی مجزا از کد،
package.json و package-lock.json تهیه کنید، بدون آنکه پوشه node_modules رایانه را منتقل کنید. اگر برنامه workspace، فایل تنظیمات یا بسته محلی دارد، آن‌ها نیز باید مطابق ساختار پروژه موجود باشند. اطلاعات محرمانه را عمومی نکنید.در پوشه آزمایشی با نسخه Node انتخاب‌شده برای سرویس:
کد / دستورpwd
ls -la package.json package-lock.json
npm ci
npm ci فقط وقتی مناسب است که فایل قفل npm معتبر و هماهنگ با package.json دارید. این فرمان هر node_modules موجود در همان پوشه را حذف می‌کند؛ آن را روی نسخه فعال یا پوشه‌ای که محتویاتش را لازم دارید اجرا نکنید. ممکن است نصب اسکریپت‌های بسته را اجرا کند، پس منبع کد، فایل قفل و registry باید قابل اعتماد باشند. تنظیماتی مانند legacy-peer-deps که هنگام ساخت فایل قفل لازم بوده‌اند نیز باید یکسان باشند.اگر فایل قفل ندارید، یک دستور خودکار برای به‌روزرسانی همه وابستگی‌ها نزنید. نسخه قفل تأییدشده را از مخزن پروژه بگیرید یا با توسعه‌دهنده در محیط توسعه بسازید و آزمایش کنید. اگر پروژه از pnpm یا yarn استفاده می‌کند، فایل قفل و روش همان ابزار را طبق نسخه پروژه به کار ببرید؛ دستور npm جایگزین بی‌قید آن‌ها نیست.
۴. اگر نصب یا ساخت ماژول شکست خورد
چند خط نخست علت و چند خط پایانی نصب را بخوانید. اگر بسته برای معماری یا نسخه مقصد فایل آماده ندارد، ممکن است به ابزار ساخت و کتابخانه‌های توسعه نیاز داشته باشد. روی هاست اشتراکی به جای اجرای
sudo یا تغییر پایتون سیستم، نام بسته، نسخه Node، معماری و پیام خطا را برای پشتیبانی بفرستید تا سازگاری سرویس بررسی شود. روی سرور مستقل هم پیش از نصب پیش‌نیازها، راهنمای همان بسته و توزیع را با نسخه پروژه تطبیق دهید.اگر خطا از
GLIBC یا کتابخانه مشترک است، نصب دوباره به‌تنهایی تضمین نمی‌کند مشکل حل شود. بسته سازگار با سیستم مقصد یا محیط ساخت همسان لازم است؛ دانلود تصادفی فایل .so و جایگزینی کتابخانه سیستم می‌تواند کل سرور را خراب کند. اگر خطا پس از تغییر نسخه Node رخ داده، نسخه تأییدشده قبلی را در محیط آزمایشی انتخاب کنید و وابستگی‌ها را همان‌جا دوباره نصب کنید.۵. نتیجه را پیش از انتشار تأیید کنید
دستور آزمون پروژه را، اگر در
کد / دستورpackage.json تعریف و برای محیط آزمایشی مناسب است، اجرا کنید:npm test
سپس برنامه آزمایشی را با روش پشتیبانی‌شده پنل اجرا و عملکردی را که از آن بسته استفاده می‌کند آزمایش کنید؛ بالا آمدن صفحه اصلی به‌تنهایی کافی نیست. بعد از تأیید، مطابق روش استقرار خود به نسخه جدید جابه‌جا شوید و نسخه قبلی را برای بازگشت نگه دارید. پوشه‌های حساس یا وابستگی‌های در حال استفاده را هنگام کار سرویس زنده جایگزین نکنید.
برای خطاهای مربوط به پیدا نشدن بسته، راهنمای Cannot find module را هم بخوانید. امکانات هاست Node.js نت‌آرام و جزئیات رفتار رسمی npm ci برای انتخاب روش نصب مفید است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام