وب پک یک نرم افزار است که در قالب یک کتابخانه و یک ابزار توسعه برای ساخت سایر نرم افزار ها در با استفاده از node استفاده می شود . این اصطلاحا نرم افزار نیازمند یک Interface برای استفاده است . webpack-cli یک کتابخانه است که همراه با وب پک برای در دسترس بودن این Command line Interface قابل استفاده است.

Webpack Coomand Line Interface

که در پکیج webpack-cli وجود دارد و در مسیر node_modules/.bin وجود دارد و ممکن است کتابخانه های مختلف را نصب کنید و command خاص دیگری به این ها اضافه کنند (معمولا پکیج های devDepedencies این قابلیت را دارند) که همگی در این مسیر لینک آن ها ساخته می شود.

npx webpack version

npx webpack help

npx webpack info

npx webpack configtest webpack.config.js

npx webpack build

npx webpack build --config ./webpack.config.js

npx webpack watch --mode development

npx webpack serve

به صورت کلی می توانیم Webpack Command Line Interface را به دو قسمت تقسیم بندی کنیم. قسمت اول Commands است که همان دستورات اصلی و قسمت دوم Flag ها است که همان option هایی است که در دستورات به کار می بریم .

برخی تنظیمات را علاوه بر این که می توان در فایل پیکره بندی قرار داد در ضمن دستورات نیز می توان از آن ها استفاده کرد. مثلا تعیین entry/output هم در فایل پیکره بندی و هم در دستور قابل قرار گرفتن است که معمولا تنظیم در فایل پیکره بندی عمومی تر است.

Webpack Configuration files

وب پک هم مثل بسیاری از Bundler ها می تواند بدون فایل پیکره بندی کار کند (اصطلاحا به آن zero configuration می گوییم) . البته که برای کارکرد پیشرفته حتما به پیکره بندی نیاز خواهیم داشت. ضمن این که ما می توانیم در زمان وارد کردن دستورات یک سری پیکره بندی ها را مداما در دستور در قالب Flag یا همان option دستور وارد کنیم که برای این که لازم نباشد که همیشه در زمان اجرای دستور این تنظیمات را وارد کنیم یک فایل پیکره بندی می سازیم و در آن این تنظیمات را قرار می دهیم.

به صورت پیش فرض فایل پیکره بندی با نام webpack.config.js در ریشه پروژه قرار دارد و در صورتی که در مسیر دیگری از پروژه دستورات را اجرا کنیم فایل تشخیص داده نخواهد شد .

module.exports = {
   mode: "development"
}

تنها option اجباری در فایل پیکره بندی همان mode است که باید تعیین گردد. سایر موارد به صورت از مقادیر پیش فرض استفاده می شود. ما در یک پروژه می توانیم فایل های پیکره بندی زیادی داشته باشیم که هر کدام به ازای حالت خاص تنظیم شده باشند (مثلا یکی برای حالت developemtn , یکیک برای حالت production و …) برای استفاده از فایل های پیکره بندی با نام های مختلف باید از Flag با نام --config استفاده کنیم.

├── build
├── node_modules
├── package.json
├── package-lock.json
├── src
├── webpack.config.common.js
├── webpack.config.dev.js
└── webpack.config.prod.js

برای اجرای هر کدام لازم است :

"scripts": {                                                                                         
   "test": "echo \"Error: no test specified\" && exit 1",   
   "build": "webpack build --config webpack.config.prod.js",
   "dev": "webpack build --config webpack.config.dev.js"
}

Mode)

مود اجرایی یک پروژه که یک از موارد development و production می باشد . این شاخصه در فایل های تنظمات اجباری است . با استفاده از این شاخصه در خود فایل تنظیمات می توان option های بخش های مختلف را شرطی تعیین کرد.

mode: "development",

همان طور که می دانید برای نصب یک کتابخانه در یک پروژه دو راه حل داریم . راه حل اول اضافه کردن اسکریپت به صورت cdn یا همان script[src] و راه حل دوم به صورت نصب ماژول از طریق ابزار npm که برای مدیریت پکیج های javascript/node می باشند.

پس هر کتابخانه یک یا چند ماژول در اختیار ما قرار می دهد. راه حل درست و استاندارد برای استفاده از این ماژول ها تجمیع آن ها با استفاده از یک Module Bundler مانند وب پک است .

از طرفی هر پروژه پس از راه اندازی  با npm و هسته مرکزی پکیج ها (package.json) به عنوان قلب پروژه با دو دسته پکیج رو به رو هستید. این دسته بندی حکم یک طبقه بندی برای پکیج ها را دارد و در نهایت مورد استفاده Module Bundler است است که زمانی که قرار است نسخه مورد نظر را توزیع کند از این طبقه بندی استفاده می کند.

• Dependencies : پکیج های محیط نهایی تولید شده در کلاینت اجرایی
• devDependencies : پکیج ها در دسته بندی توسعه

از Module Bundler نیز از دو مود اجرایی دارد که با توجه به آن ها ممکن است تنظیمات مختلفی داشته باشند. توزیع در هر یک از این مود ها در کلاینت نهایی اجرا می شود اما ممکن است تفاوت هایی در این مود ها از نظر پیکره بندی وجود داشته باشد:

• development : مود توسعه . در این مود سرعت بیلد مهم است و خوانایی کد تولید شده به دلیل دسترسی به سورس اصلی یعنی دایرکتوری src بسیار مهم است .در این مود لازم است بدانید سرعت بیلد مهم است . ما دو نوع بیلد داریم . نوع اول Build و نوع دوم reBuild است . تنظیماتی که حالت reBuild را با سرعت بیشتری (performance) انجام می دهد باید در مود development ایجاد بشوند به طور مثال devtool .
• production : در این مود معمولا یک بار بیلد برای ارسال به کلاینت لازم است و باید این کد بهینه و تا حدی خوانا باشد.به دلیل این که این بیلد یک بار اتفاق می افتد از بهینه سازی آیتم های بیلد صرف نظر می کنیم.

Entry/Output point)

در entry از آدرس نسبی یا همان Relative Path استفاده می کنیم.ممکن است با توجه به صفحات مختلف نقاط entry point های مختلفی داشته باشیم . این مقدار می تواند نقطه شروع یا Entry point یا Starting Point برای گراف وابستگی باشد . بقیه assets ها برای این شاخه از گراف در همین فایل می باشد و در نهایت Bundle که بر همین اساس ایجاد می شود این Assets ها را دارد. ساختار فایل زیر را در نظر بگیرید:

.
├── dist
│   ├── about.js
│   └── index.js
├── package.json
├── package-lock.json
├── src
│   ├── about.js
│   └── index.js
└── webpack.config.js

در ساختار بالا ما دایرکتوری src مسیر ماژول های خام ما است و dist لیست فایل هایی است که از آن بیلد گرفته می شود و برای کلاینت قابل خواندن است (به عبارتی همان دایرکتوری Bundle ها) . در مسیر src ما دو نقطه شروع داریم که معادل هر کدام از آن ها در dist یا همان دایرکتوری خروجی Bundle آن بوجود آمده است. در این مسیر قرار است .این حالتی است که ما پیکره بندی آن را به گونه ای تنظیم می کنیم که دو نقطه شروع و دو Bundle خروجی برای آن داشته باشیم.

در این بخش نقطه شروع هر Bundle را تعیین می کنیم. به طور مثال اگر قرار است به ازای هر صفحه یک Bundle خاص داشته باشیم نقطه شروع و Bundle نهایی را در آن تنظیم خواهیم کرد.

entry: {
  index: './src/index.js',
  about: './src/about.js',
},
output: {
  filename: '[name].js',
  path: __dirname + '/dist'
}

همچنین در output گزینه filename اختیاری است و به صورت پیش فرض نام entry می باشد و همچنین می توان از descriptor های نظیر [name] , [ext] , [contenthash] استفاده کرد.هر کدام از این descriptor ها معنی خود را دارند:

• [name] : دقیقا همان نام فایل در entry point
• [contenthash] : این مورد یک hash به ازای تغییرات در انتهای فایل معمولا اضافه می شود و کاربر آن در cash busting می باشد.
• [ext] : فرمت فایل که معمولا در این قسمت js می باشد.

همچنین باید path به صورت آدرس حقیقی یا Absolute Path باشد که از __dirname (dunder dirname) استفاده می کنیم.یک ماژول کاربردی برای این مسیر دهی حقیقی داریم که نام آن path می باشد و برای استفاده از آن لازم است که ماژول path را درون ریزی کنیم.

const path = require('path')
const config = { 
    entry: {
        index: './src/index.js',
    },  
    output: {
        filename: '[name][contenthash].js',
        path: path.resolve(__dirname,'./build'),
    },  
}
module.exports = config

Modules)

همان طور که پیش تر گفتیم وب پک با زبان Node کار می کند و ماژول ها و asset های غیر از جاوا اسکریپت را به صورت پیش فرض نمی شناسد . پس از نصب loader های مختلف نظیر file-loader باید تنظیمات آن را در این بخش تعیین کنیم.

این نکته را در نظر داشته باشید ماژول ها و پلاگین ها و خود وب پک دقیقا همان پکیج های جاوا اسکریپت هستند و از نظر ماهیت دقیقا یکسان اند. این پکیج ها در هر مرحله از نصب با توجه به وابستگی های خود نقش جدیدی دریافت می کنند. به طور مثال اگر شما بخواهید یک ماژول Loader برای تفسیر sass برای وب پک نصب کنید ابتدا از شما برای نصب وابستگی های آن ها یعنی همان وب پک درخواست خواهد شد.

• Javascript devDependencies
  • Webpack (Module Bundler)
    • Models
      • Loaders
    • Plugins
• Javascript Dependencies
  • jalali moment

همان طور که در بالا اشاره شد لیست پکیج های یک پروژه را در یک راستا بررسی کردیم و متوجه شدیم که کل این نمودار همگی پکیج های جاوا اسکریپت هستند و با توجه به وابستگی های خود نقش های مختلفی را دریافت می کنند. برای نصب نیز دقیقا مطابق با دستور نصب پکیج های npm عمل خواهیم کرد.

(Dependency jalali moment) نصب یک نمونه پیکج در قالب Dependencies برای کار با کتابخانه جلالی . این پکیج در قالب خروجی کلاینت هم وجود خواهد داشت.

npm i jalali-moment --save

(devDependency sass-loader) نصب یک نمونه پکیج در قالب Loader برای وب پک در قالب devDependencies

npm install sass-loader sass webpack --save-dev

Plugins)

همان طور که پیش تر گفته شد پلاگین ها و ماژول ها و خود وب پک و ابزار های آن همگی پکیج هایی هستند که یک اکوسیستم را تشکیل می دهند. این اکوسیستم ابزارهایی برای بهبود فرآیند پردازش سورس و تشکیل کدهای نهایی در قالب پلاگین در اختیار ما قرار می دهد.

پلاگین های مختلفی که با اهداف compile , minify , shim , chunk , bundle نصب می کنیم. برخی از این پلاگین ها هم در بخش های دیگر مثل Loader ها نیز مورد استفاده قرار می گیرند مثل mini-css-extract-plugin . پلاگین ها کلاس هایی هستند که در این آرایه instanciate می شوند.

plugins: [
  new MiniCssExtractPlugin(),
],

برای استفاده از یک پلاگین در صورت نیاز باید آن را در آرایه plugins سازنده آن را اجرا کنیم (instance) و در این آرایه قرار بدهیم . برخی زمان ها لازم است که در بخش های دیگری از فایل تنظیمات نیز از ماژول های این پلاگین استفاده کنیم.

optimization)

این بخش از تنظیمات قرار است در رابطه با بهینه سازی Assets های پروژه تنظیماتی را بر اساس پلاگین هایی که نصب کرده ایم و همچنین تنظیمات پیش فرض وب پک تعیین کنیم. این شامل minify کردن css, js فایل ها می شود . برای این کار ما دو پلاگین داریم . پلاگین terser-webpack-plugin برای بهینه کردن کدهای Javascript و پلاگین css-minimizer-webpack-plugin برای بهینه کردن کدهای css.

optimization: {
  minimize: true,
    minimizer: [
      new TerserPlugin(),
      new CssMinimizerPlugin(),
    ]   
}

در نهایت می توان گفت تمامی مراحل بالا این ابزار توسعه به صورت گام به گام در ابتدا برای راه اندازی اولیه انجام می شود و پس از این که راه اندازی اولیه انجام شد شروع به توسعه پروژه می کنیم و مرحله به مرحله در خلال توسعه منطق اصلی پروژه لازم باشد که هر یک از موارد بالا را تکرار کنیم. از قبیل نصب پلاگین . نصب Loader پیکره بندی مجدد بر اساس پلاگین ها یا ماژول های جدید و سایر مراحل.