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

رفع ERR_REQUIRE_ESM در Node.js؛ چطور import و require را هماهنگ کنیم؟

تشخیص تفاوت CommonJS و ES Module، بررسی نسخه Node و حل امن خطای ERR_REQUIRE_ESM در هاست.

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع ERR_REQUIRE_ESM در Node.js؛ چطور import و require را هماهنگ کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
برنامه Node.js هنگام اجرا پیام ERR_REQUIRE_ESM می‌دهد. معمولاً کدی که با روش قدیمی‌تر require نوشته شده، تلاش می‌کند بسته‌ای را بارگذاری کند که به صورت ES Module ارائه شده است. تفاوت نسخه Node و نسخه بسته هم می‌تواند باعث شود همان کد روی رایانه کار کند ولی روی هاست خطا بدهد.
رفتار نسخه‌های Node یکسان نیست: نسخه‌های جدیدتر در شرایط مشخص می‌توانند بعضی ES Moduleهای همگام را با require بارگذاری کنند، اما ماژولی با top-level await و بعضی حالت‌های سازگاری همچنان نیاز به روش دیگری دارد. بنابراین قبل از تغییر همه فایل‌های پروژه، محیط و بسته مشکل‌دار را مشخص می‌کنیم.

۱. نسخه محیط اجرا و بسته خطادار را ببینید

در Terminal یا SSH، وارد کپی آزمایشی پوشه برنامه شوید:
کد / دستورcd ~/node-app-test pwd node --version npm --version npm ls --depth=0
مسیر نمونه را با مسیر خود عوض کنید. گزارش خطا معمولاً نام فایل پروژه و بسته‌ای را که در require(...) بارگذاری شده نشان می‌دهد. نسخه Node انتخاب‌شده در پنل هاست را هم ببینید؛ اگر پنل فرمان ورود به محیط برنامه دارد، آن را اجرا و نسخه ترمینال را دوباره مقایسه کنید.
فایل package.json همان بسته را بخوانید:
کد / دستورcat package.json
مقدار type، پسوند فایل و فرمان start در تشخیص نوع کد کمک می‌کنند. فایل .mjs به طور معمول ES Module و .cjs برای CommonJS است. تفسیر .js به تنظیم بسته و نسخه Node بستگی دارد؛ پروژه‌های تو در تو می‌توانند تنظیم متفاوت داشته باشند.

۲. یک نمونه ساده از دو روش بسازید

در یک پوشه آزمایشی جدا، فایل greet.mjs بسازید:
کد / دستورexport function greet(name) { return 'Hello ' + name; }
در فایل test.cjs کنار آن بنویسید:
کد / دستور(async () => { const moduleValue = await import('./greet.mjs'); console.log(moduleValue.greet('Netaram')); })().catch((error) => { console.error(error); process.exitCode = 1; });
حالا در همان پوشه:
کد / دستورnode test.cjs
در نسخه سازگار Node باید Hello Netaram چاپ شود. import() یک Promise برمی‌گرداند؛ بنابراین کد وابسته به نتیجه باید منتظر آن بماند. این تغییر همیشه با جایگزینی یک کلمه در پروژه واقعی تمام نمی‌شود. نام export بسته نیز ممکن است default باشد نه تابع نام‌دار؛ مستندات همان بسته را بخوانید.

۳. برای پروژه واقعی کدام راه مناسب است؟

اگر فقط یک بسته ESM مشکل دارد و نسخه Node پروژه از import() پویا پشتیبانی می‌کند، در نسخه آزمایشی می‌توانید همان محل بارگذاری را به الگوی غیرهمگام تبدیل کنید. سپس همه کدهایی را که فوراً به نتیجه احتیاج دارند بررسی کنید. اگر import داخل callback یا فایل شروع است، رسیدگی به خطا و ترتیب آماده‌شدن برنامه مهم است.
اگر کل پروژه قرار است به ESM مهاجرت کند، تغییر "type": "module" در package.json می‌تواند تفسیر بسیاری از فایل‌های .js را عوض کند. در این حالت require، module.exports، مسیر فایل‌ها و بعضی ابزارهای قدیمی ممکن است نیاز به تغییر داشته باشند. این تبدیل را در شاخه آزمایشی و با آزمون‌های پروژه انجام دهید، نه با افزودن سریع یک گزینه روی سایت فعال.
راه دیگر استفاده از نسخه‌ای از بسته است که با ساختار و نسخه Node پروژه سازگار و همچنان از نظر امنیتی پشتیبانی می‌شود. نسخه را براساس مستندات، فایل قفل و سیاست به‌روزرسانی انتخاب کنید؛ برگشت به نسخه قدیمی و آسیب‌پذیر صرفاً برای حذف خطا مناسب نیست.

۴. اگر نسخه جدید Node دارید اما خطا ادامه دارد

قابلیت require(esm) در نسخه‌های مختلف Node تدریجی تغییر کرده و شرایطی دارد. اگر ماژول یا وابستگی آن top-level await داشته باشد، نسخه‌های پشتیبان ممکن است خطای ERR_REQUIRE_ASYNC_MODULE بدهند. در این حالت import() و کد غیرهمگام را بررسی کنید. از شماره نسخه و مستندات همان نسخه استفاده کنید، نه از این فرض که همه نسخه‌های جدید رفتار یکسان دارند.
اگر برنامه واقعاً به نسخه جدیدتری نیاز دارد، فیلد engines پروژه و نیازهای همه وابستگی‌های اصلی را بخوانید. نسخه پشتیبانی‌شده را ابتدا برای یک برنامه آزمایشی در پنل انتخاب و نصب وابستگی‌ها و آزمون‌ها را با فایل قفل پروژه تکرار کنید. تغییر نسخه در برنامه زنده ممکن است ماژول بومی یا ابزار build دیگری را ناسازگار کند؛ نسخه قبلی و روش برگشت را نگه دارید. اگر پنل نسخه لازم را ارائه نمی‌دهد، از پشتیبانی درباره گزینه سازگار بپرسید.
اگر خطای تازه Cannot find module است، نام بسته، مسیر و محیط نصب را با راهنمای پیدا نشدن ماژول بررسی کنید. اگر فایل خروجی TypeScript پیدا نمی‌شود، مسئله build جداگانه است و راهنمای dist کمک می‌کند.

۵. تغییر را پیش از فعال‌سازی تأیید کنید

آزمون‌های پروژه و مسیری را که از بسته مشکل‌دار استفاده می‌کند در محیط آزمایشی اجرا کنید. سپس نسخه آزمایشی را با همان نسخه Node و روش اجرای پنل بالا بیاورید. پس از تأیید، طبق روند استقرار خود تغییر را فعال کنید و نسخه پیشین و فایل قفل را برای بازگشت نگه دارید.
مشخصات هاست Node.js نت‌آرام و جزئیات سازگاری در مستندات Node.js آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

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

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