آموزش جامع Webpack (بخش سوم: فایل پیکربندی و سرور توسعه محلی) — از صفر تا صد

۸۹ بازدید
آخرین به‌روزرسانی: ۰۵ مهر ۱۴۰۲
زمان مطالعه: ۵ دقیقه
آموزش جامع Webpack (بخش سوم: فایل پیکربندی و سرور توسعه محلی) — از صفر تا صد

در بخش قبلی این سری مقالات آموزشی دیدیم که برای transpile کردن کد خود به BabelJs نیاز داریم و با روش ارسال فایل‌ها از سوی Webpack به پارسر دیگری مانند BabelJS آشنا شدیم. تا به اینجا Webpack را بدون هیچ گونه فایل پیکربندی اجرا کرده‌ایم. در این بخش قصد داریم نخستین فایل پیکربندی را بسازیم، با روش استفاده از loader آشنا شویم و یک سرور توسعه محلی راه‌اندازی کنیم. برای مطالعه بخش قبلی این سری مقالات آموزشی روی لینک زیر کلیک کنید:

الزامات Babel

ابتدا باید وابستگی‌های زیر را نصب کنیم:

yarn add @babel/core @babel/preset-env babel-loader –dev

توضیح هر یک از این وابستگی‌ها به شرح زیر است:

  • Babel Core: همه منطق لازم برای تبدیل و همچنین برخی pollyfil-ها را دارد.
  • Babel Preset Env: امکان انتخاب تبدیل/پلی‌فیل های صحیح را بسته به لیست مرورگر هدف فراهم می‌سازد.
  • Babel Loader: مسئول دریافت فایل ورودی از Webpack و ارسال آن از طریق BabelJS است.

فایل‌های پیکربندی

در این بخش فایل‌های پیکربندی را توضیح می‌دهیم.

Babel

ابتدا Babel را برای استفاده از preset-env تنظیم می‌کنیم. به این منظور یک فایل به نام babelrc. با این محتوا بسازید:

1{
2  "presets": ["@babel/preset-env"]
3}

و یک بازه لیست مرورگر روی فایل package.json تعیین می‌کنیم:

1"browserslist": [
2  "last 2 versions",
3  "not dead"
4]

نکته: ما مشغول ایجاد یک کوئری ژنریک زیبا هستیم. در مورد اپلیکیشن‌های پروداکشن باید همواره analytics را بررسی کنید تا مرورگرهای هدف خود را به درستی انتخاب کنید.

در ادامه به بررسی تعداد مرورگرهایی که با این کوئری هدف‌گیری می‌شوند می‌پردازیم.

npx browserslist

از آنجا که نمی‌خواهیم browserslist را صرفاً برای یک اجرای منفرد نصب کنیم آن را مستقیماً از طریق npx نصب می‌کنیم. خروجی به صورت زیر خواهد بود:

سرور توسعه محلی

بنابراین یکی از کمترین موارد transpile یا polyfill کردن احتمالاً اینترنت اکسپلورر و نسخه موبایل آن خواهد بود. چنان که قبلاً گفتیم نباید از کوئری‌هایی استفاده کرد که خیلی کلی هستند، به جای آن باید لیست را بر مبنای داده‌های استفاده از مخاطبان هدف ساخت.

Webpack

ما اکنون کافی است به Webpack اعلام کنیم که فایل‌های جاوا اسکریپت باید از طریق babel ارسال شوند. در ادامه فایل webpack.config.js را روی دایرکتوری ریشه پروژه می‌سازیم و کد زیر را به آن اضافه می‌کنیم:

1module.exports = {
2  module: {
3    rules: [
4      {
5        test: /\.js$/,
6        use: "babel-loader"
7      }
8    ]
9  }
10};

پیکربندی Webpack صرفاً یک ماژول NodeJS است که «شیء پیکربندی» (configuration object) را اکسپورت می‌کند.

اگر از «عبارت‌های منظم» (Regex) چندان سر درنمی‌آورید، باید اشاره کنیم که عبارت فوق موجب می‌شود همه فایل‌هایی که به ‎.js ختم می‌شوند، تطبیق پیدا کنند.

ما باید اقدام به escape کردن «.» از «js.» کنیم زیرا در زبانشناسی ریجکس به عنوان یک ماسک برای «هر کاراکتر» استفاده می‌شود و ما نمی‌خواهیم که چنین شود، چون منظور ما صرفاً یک علامت نقطه است.

سپس از $ استفاده می‌کنیم که با استفاده از آن تطبیق باید درست پس از ‎.js خاتمه یابد و از این رو دیگر با مواردی که به ‎.json ختم می‌شوند مواجه نخواهیم شد.

شاید برخی فکر کنند که باید همه پیکربندی‌های babel و browserslist را درون پیکربندی Webpack قرار داد، اما باید اشاره کنیم که هر دو پیکربندی‌های babel و browserslist معمولاً اندازه یکسانی دارند. در هر حال پیکربندی Webpack به مرور افزایش می‌یابد، بنابراین یکی از کلیدهای حفظ انسجام آن این است که تا حد امکان ماژولار باشد. مانند هر سورس کد نرمال دیگر، اگر دیدید که حجم آن افزایش پیدا می‌کند، با فرض وجود مسئولیت‌های زیاد و کدهای تکراری، باید آن را تجزیه کنید.

محیط توسعه

برای توسعه هر اپلیکیشن/سایت باید یک محیط dev بسازیم که در آن می‌توانیم تست کنیم و به‌روزرسانی‌ها را بی‌درنگ ببینیم. از آنجا که تاکنون کد خود را عملاً در حال اجرا در مرورگر ندیده‌ایم، اینک نوبت این کار رسیده است.

سرور توسعه Webpack

از آنجا که احتمالاً می‌دانید یا شاید شنیده باشید Webpack یک ابزار بسیار عالی به نام webpack-dev-server دارد که با استفاده از آن می‌توانید یک سرور HTTP را روی ماشین خودتان با قابلیت hot module reloading شبیه‌سازی کنید. این امکانی بسیار زیبا است، زیرا مرورگر هر بار که کامپایل آغاز شود مجدداً بارگذاری می‌شود و دیگر لازم نیست هر صفحه را به صورت دستی در زمان تغییر دادن کد بارگذاری کنید.

نصب

ما هر دو سرور dev مربوط به Webpack و همچنین پلاگین تولید index.html را نصب می‌کنیم:

yarn add webpack-dev-server html-webpack-plugin –dev

راه‌اندازی

در پیکربندی وب‌پک پلاگین را به بخش plugins اضافه می‌کنیم:

1const HtmlWebpackPlugin = require("html-webpack-plugin"); // first import ...
2
3module.exports = {
4  module: {
5    rules: [
6      {
7        test: /\.js$/,
8        use: "babel-loader"
9      }
10    ]
11  },
12  plugins: [
13    new HtmlWebpackPlugin() // ... then register it
14  ]
15};

نکته: اگر نمی‌خواهید در فایل index.html روی build-های پروداکشن خروجی داشته باشید، می‌توانید با بررسی argv.mode وب‌پک از این کار جلوگیری کنید:

1// To prevent argv being undefined, let's use a default value
2module.exports = (env={}, argv={}) => ({
3  // ...
4  plugins: [
5    // Any option given to Webpack client can be captured on the "argv"
6    argv.mode === "development" ? new HtmlWebpackPlugin() : null
7  ].filter(
8    // To remove any possibility of "null" values inside the plugins array, we filter it
9    plugin => !!plugin
10  )
11});

برخی توضیحات برای کد فوق

وب‌پک هم یک شیء و هم یک تابع به عنوان پیکربندی می‌پذیرد. زمانی که به صوت تابع عرضه شده باشد، اقدام به تزریق env و argv به صورت پارامتر می‌کند:

  • Env: هر چیزی که کلاینت (webpack-cli) دریافت می‌کند، تحت پارامترهای env و به صورت مشخصه شیء env قرار می‌گیرد. برای نمونه:
--env.test or --env.customValue="Hello there!"
  • Argv: همه آرگومان‌های ارائه شده به پیکربندی Webpack که بخشی از طرح کلی پیکربندی هستند مثلاً:
--mode=production

از آنجا که ما از مراحل ساده شروع به کار کرده‌ایم، هنوز نیازی به ایجاد دو فایل پیکربندی یکی برای توسعه و دیگری برای پروداکشن نداریم و همچنان از این روند ساده‌سازی خود پیروی می‌کنیم.

اکنون زمان آن رسیده است که سرور را اجرا کنیم. این سرور همان آرگومان‌هایی را می‌پذیرد که کلاینت وب‌پک قبول می‌کند. علاوه آن برخی پارامترهای دیگر نیز دارد. بنابراین در ادامه build:dev را در package.json حذف کرده و به صورت زیر تغییر می‌دهیم:

1"scripts": {
2  "build": "webpack --mode=production",
3  "start:dev": "webpack-dev-server --mode=development"
4},

آن را تست می‌کنیم:

yarn start:dev

در این مرحله باید چیزی مانند زیر ببینید:

سرور توسعه محلی

اکنون صفحه را در آدرس http://localhost:8080 باز کنید. سپس ابزارهای dev را در برگه کنسول باز کنید تا با عبارت زیر مواجه شوید:

Hello OLX Dev!!

source maps

اگر روی لینکی که پس از نتیجه console.log در لاگ کنسول عرضه شده کلیک کنید به پنل sources می‌رسید و چیزی مانند زیر را می‌بینید:

سرور توسعه محلی

این کد transpile شده از سوی Babel است. برای بررسی کد واقعی باید وارد source maps بشوید.

source maps چیزی‌ است که سورس کد واقعی شما را به سورس بسته‌بندی‌شده نگاشت می‌کند و امکان استفاده از «نقاط توقف» (breakpoints) و دیدن خطوط کد واقعی را در ردگیری پشته در صورت بروز استثنا فراهم می‌سازد. برای فعال‌سازی آن‌ها کافی است کد زیر را به فایل webpack.config.js اضافه کنید:

devtool: "source-map",

سرور dev را متوقف و سپس بار دیگر اجرا کنید و سورس را در لینک زبانه کنسول بررسی کنید تا این بار ببینید که سورس کد واقعی نمایش پیدا کرده است.

سخن پایانی

اینک ما موفق شده‌ایم همه چیز را آماده کنیم و سرور توسعه خود را اجرا نماییم. بدین ترتیب مسیر افزودن loader-های بیشتر و تجزیه همه انواع فایل‌ها هموار شده است. در بخش بعدی به این بحث بیشتر خواهیم پرداخت. برای مطالعه بخش بعدی روی لینک زیر کلیک کنید:

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

بر اساس رای ۱ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
tech.olx
نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *