npm, Vite, ESLint আর Prettier — পেশাদার JavaScript-এর টুলবক্স

১ · আপনার কোড একা চলে না — package, registry আর toolchain

এতদিন এই কোর্সে আপনি যে কোড লিখেছেন, তার প্রায় সবটাই আপনার নিজের। কিন্তু একটি আসল অনলাইন দোকানের ওয়েবসাইট খুলে তার ফোল্ডারে তাকালে অন্য ছবি দেখবেন। আপনার লেখা হয়তো ৫,০০০ লাইন, অথচ node_modules ফোল্ডারে অন্যদের লেখা কয়েক লাখ লাইন। তারিখ ফরম্যাট করার কোড, ছবি ছোট করার কোড, টেস্ট চালানোর কোড — এগুলো আপনি লেখেননি, নামিয়ে এনেছেন। প্রতিটি এমন কোডের বান্ডিলকে বলে package, আর আপনার প্রজেক্ট যেসব package-এর ওপর নির্ভর করে, সেগুলো তার dependency.

Package-গুলো থাকে একটি কেন্দ্রীয় ভান্ডারে — npm registry (registry.npmjs.org). এটি পৃথিবীর সবচেয়ে বড় সফটওয়্যার registry; এখানে লাখ লাখ package আছে। Registry থেকে package নামানো, version মেলানো আর ফোল্ডারে সাজানোর কাজ করে একটি package manager. Node.js-এর সাথে যেটি আসে, তার নামও npm — registry আর টুল, দুটোর নামই এক, তাই প্রথমে একটু গুলিয়ে যায়।

Package নামানোই শেষ নয়। পেশাদার দলে কোড লেখার চারপাশে আরও কয়েকটি টুল কাজ করে — সব মিলিয়ে বলে toolchain:

২ · package.json — প্রজেক্টের পরিচয়পত্র

প্রতিটি npm প্রজেক্টের মূল ফোল্ডারে থাকে একটি package.json ফাইল। এটি প্রজেক্টের পরিচয়পত্র: নাম কী, কোন version, কোন package লাগে, কোন কমান্ডে কী চলে। নতুন প্রজেক্টে npm init -y চালালে একটি খালি পরিচয়পত্র তৈরি হয় (-y মানে সব প্রশ্নে ডিফল্ট উত্তর)। আমাদের “দোকান” প্রজেক্টের package.json দেখতে এমন:

{
  "name": "dokan",
  "version": "1.0.0",
  "private": true,
  "type": "module",
  "engines": { "node": ">=20.19" },
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "lint": "eslint .",
    "format": "prettier --write .",
    "test": "vitest run"
  },
  "dependencies": {
    "dayjs": "^1.11.13"
  },
  "devDependencies": {
    "eslint": "^10.0.0",
    "prettier": "^3.6.0",
    "vite": "^8.3.0",
    "vitest": "^5.0.0"
  }
}

dependencies, devDependencies আর peerDependencies

এই ভাগের ব্যবহারিক মানে আছে। npm install -D eslint (বা --save-dev) devDependencies-এ যোগ করে, আর npm install dayjs dependencies-এ। সার্ভারে শুধু চালানোর জন্য npm ci --omit=dev দিলে devDependencies আসেই না — ছোট আর নিরাপদ ইনস্টল। peerDependencies কেন? ধরুন একটি date-picker library নিজের ভেতরে React-এর আলাদা কপি আনল। তখন পাতায় দুটি React চলবে, আর React-এর hook ভেঙে পড়বে। তাই library বলে দেয়: “React আনবে অ্যাপ নিজে, আমি শুধু সেটির সাথে মিলে চলি।” npm 7 থেকে peerDependencies নিজে থেকেই ইনস্টল হয়, আর version না মিললে ERESOLVE error দেয় — তখন --legacy-peer-deps দিয়ে চাপা না দিয়ে আগে বুঝুন কোন version কোনটি চায়।

যদি আপনি নিজে একটি library প্রকাশ করেন, আরও দুটি ঘর লাগে। main — পুরোনো ধরনের প্রবেশপথ, অর্থাৎ import "x" করলে কোন ফাইল খুলবে। আধুনিক exports — কোন পথ বাইরে থেকে import করা যাবে, আর ESM ও CommonJS-এর জন্য আলাদা ফাইল: "exports": { ".": { "import": "./dist/index.js", "require": "./dist/index.cjs" } }. exports থাকলে তালিকার বাইরের ফাইল (x/src/internal.js) import করা যায় না — library-র ভেতরের অংশ লুকানোর এটাই উপায়।

npm scripts — প্রজেক্টের কাজের শর্টকাট

npm scripts দলের সবার জন্য একই কমান্ড নিশ্চিত করে। নতুন কেউ এসে জানতে চায় না “build কীভাবে করি?” — তিনি শুধু npm run build চালান। দুটি নিয়ম মনে রাখুন। প্রথমত, script চলার সময় npm node_modules/.bin ফোল্ডারটি PATH-এ যোগ করে দেয়, তাই "build": "vite build" লিখলে প্রজেক্টে ইনস্টল করা vite-ই চলে — global vite লাগে না। দ্বিতীয়ত, pre আর post নামের script থাকলে সেগুলো আগে-পরে নিজে থেকে চলে। test, start আর কয়েকটির ছোট রূপ আছে (npm test), বাকিগুলোর জন্য npm run নাম. নিচের কোডটি npm-এর এই আচরণের একটি ছোট নকল — চালিয়ে দেখুন:

const pkg = {
  name: "dokan", version: "1.0.0", private: true, type: "module",
  scripts: {
    dev: "vite", prebuild: "eslint .", build: "vite build",
    postbuild: "node scripts/size-report.js", test: "vitest run",
  },
  dependencies: { dayjs: "^1.11.13" },
  devDependencies: { vite: "^8.3.0", eslint: "^10.0.0", vitest: "^5.0.0" },
};

function npmRun(task) {
  if (!pkg.scripts[task]) return console.log(`npm error Missing script: "${task}"`);
  for (const step of [`pre${task}`, task, `post${task}`]) {
    if (pkg.scripts[step]) console.log(`> ${pkg.name}@${pkg.version} ${step}\n> ${pkg.scripts[step]}`);
  }
}

npmRun("build");
npmRun("deploy");
console.log("ব্যবহারকারীর ব্রাউজারে যায়:", Object.keys(pkg.dependencies));
console.log("শুধু ডেভেলপারের যন্ত্রে:", Object.keys(pkg.devDependencies));

৩ · npm install ভেতরে কী করে — node_modules, lockfile আর npm ci

package.json-এ লেখা থাকে ইচ্ছা — “vite চাই, 8.3.0 বা তার পরের কোনো 8.x”. কিন্তু ফোল্ডারে বসাতে হবে একটি নির্দিষ্ট version, আর vite নিজেও আরও কিছু package-এর ওপর নির্ভর করে, সেগুলোও আরও কিছুর ওপর। আপনি সরাসরি যা চাননি অথচ আসছে, সেগুলো transitive dependency. আমরা একটি খালি Vite প্রজেক্টে মাত্র একটি devDependency (vite) রেখে npm ci চালিয়েছিলাম — এল ১৫টি package. বড় React অ্যাপে এই সংখ্যা সহজেই এক হাজার ছাড়ায়। নিচের ডায়াগ্রামে দেখুন একটি npm install কোন কোন ধাপে কাজ করে:

"devDependencies": {
  "vite": "^8.3.0"     // 8.3.0 ≤ version < 9.0.0
}

"versions": { … "8.2.1", "8.3.0", "8.3.1", … "8.3.4", "9.0.0-beta.0" … }
"8.3.4": { "dependencies": { "rolldown": "~1.2.12",
           "postcss": "^8.5.29", "lightningcss": "^1.33.0", … } }

vite ^8.3.0          → 8.3.4
├─ rolldown ~1.2.12  → 1.2.14
├─ postcss ^8.5.29   → 8.5.31
│  └─ nanoid ^3.3.11 → 3.3.20
└─ lightningcss …    → 1.33.0 (+ শুধু এই OS-এর binary)

"node_modules/vite": {
  "version": "8.3.4",
  "resolved": "https://registry.npmjs.org/vite/-/vite-8.3.4.tgz",
  "integrity": "sha512-…",   // নামানো ফাইলের hash
  "dev": true
}

$ npm ci
added 15 packages, and audited 16 packages in 634ms
$ ls node_modules
@oxc-project  @rolldown  lightningcss  nanoid  postcss
picocolors  rolldown  vite  .bin/  …

শেষ ধাপের সমতল গাছের একটি পার্শ্বপ্রতিক্রিয়া আছে। postcss-এর dependency হিসেবে nanoid উপরের স্তরে বসেছে, তাই আপনার কোডে import { nanoid } from "nanoid" লিখলে কাজ করে যাবে — যদিও package.json-এ আপনি nanoid চাননি। একে বলে phantom dependency. কোনো দিন postcss nanoid ব্যবহার বন্ধ করলে আপনার অ্যাপ কোনো কারণ ছাড়াই ভেঙে যাবে। নিয়ম: যা import করবেন, তা package.json-এ নিজে লিখুন।

package-lock.json কেন commit করবেন — আর npm ci কেন

ধরুন রাফি আজ প্রজেক্ট শুরু করলেন, vite পেলেন 8.3.4. তিন সপ্তাহ পরে নতুন সহকর্মী নাদিয়া একই package.json নিয়ে install করলেন। এর মধ্যে 8.4.0 বেরিয়েছে, যা ^8.3.0-এর সীমায় পড়ে। lockfile না থাকলে নাদিয়া পাবেন 8.4.0 — একই কোড, ভিন্ন টুল। কোনো বাগ শুধু নাদিয়ার যন্ত্রে দেখা দিলে কেউ বুঝবে না কেন। lockfile থাকলে দুজনেই পাবেন হুবহু একই গাছ, এমনকি transitive dependency-গুলোও। তাই অ্যাপের জন্য package-lock.json সবসময় Git-এ commit করুন।

আপডেট হোক সচেতন সিদ্ধান্ত: npm outdated দেখায় কোনটির নতুন version আছে, npm update সীমার ভেতরে আপডেট করে lockfile বদলায়, npm install vite@9 সীমার বাইরে যায়। তারপর lockfile-সহ commit, যাতে রিভিউতে বদলটা দেখা যায়।

৪ · Semantic versioning — ^, ~ আর একটি সংখ্যার পেছনের প্রতিশ্রুতি

প্রায় সব npm package semantic versioning (semver) মেনে version দেয়: MAJOR.MINOR.PATCH, যেমন 1.4.2. প্রতিটি অংশ একটি প্রতিশ্রুতি:

• PATCH (1.4.2 → 1.4.3): শুধু বাগ ঠিক; আচরণ যেমন ছিল তেমন থাকার কথা।
• MINOR (1.4.2 → 1.5.0): নতুন সুবিধা যোগ, কিন্তু পুরোনো কোড না বদলেই চলবে।
• MAJOR (1.4.2 → 2.0.0): breaking change — কোনো function সরানো, নাম বা আচরণ বদলানো; আপনার কোড বদলাতে হতে পারে।
• Pre-release (2.0.0-beta.1): হাইফেনের পরের অংশ মানে pre-release — পরীক্ষামূলক। ক্রমে এটি 2.0.0-এর আগে।

package.json-এ সাধারণত একটি নির্দিষ্ট version নয়, একটি সীমা লেখা হয়, যাতে বাগ ঠিক আর নতুন সুবিধা আপনি পান। দুটি চিহ্ন সবচেয়ে বেশি দেখবেন: caret (^) — npm install ডিফল্টে এটিই লেখে — আর tilde (~). নিচে একই ভিত্তি 1.4.2 দিয়ে দুটি সীমার সামনে একের পর এক version রেখে দেখুন:

0.x-এর বিশেষ নিয়ম

Semver-এর নিয়মে 1.0.0-এর আগে “যেকোনো কিছু যেকোনো সময় বদলাতে পারে।” তাই npm 0.x-এ caret-কে আরও কড়া করে: ^0.4.2 মানে 0.4.x (≥0.4.2) — এখানে minor-ই যেন major; আর ^0.0.3 মানে শুধু 0.0.3. নিয়মটি এক বাক্যে: caret বাঁ দিক থেকে প্রথম অশূন্য অংশটি বদলাতে দেয় না। নিচের কোডে এই নিয়মগুলোর একটি ছোট, নিজে লেখা সংস্করণ — চালিয়ে দেখুন উপরের ডায়াগ্রামের সাথে মেলে কি না:

// ছোট semver checker — শুধু ^ আর ~ (pre-release বাদ)
const parse = (v) => v.split(".").map(Number);
function satisfies(version, range) {
  const op = range[0];
  const [M, m, p] = parse(range.slice(1));
  const [vM, vm, vp] = parse(version);
  const atLeast = vM !== M ? vM > M : vm !== m ? vm > m : vp >= p;
  if (!atLeast) return false;                    // নিচের সীমার নিচে
  if (op === "~") return vM === M && vm === m;   // শুধু patch বাড়তে পারে
  if (M > 0) return vM === M;                    // ^1.x.x: major একই থাকবে
  if (m > 0) return vM === 0 && vm === m;        // ^0.4.x: minor-ই এখানে "major"
  return vM === 0 && vm === 0 && vp === p;       // ^0.0.3: শুধু এই একটি
}
const checks = {
  "^1.4.2": ["1.4.1", "1.4.9", "1.9.0", "2.0.0"], "~1.4.2": ["1.4.9", "1.5.0"],
  "^0.4.2": ["0.4.7", "0.5.0"], "^0.0.3": ["0.0.3", "0.0.4"],
};
for (const [range, versions] of Object.entries(checks)) {
  const row = versions.map((v) => `${v} ${satisfies(v, range) ? "হ্যাঁ" : "না"}`);
  console.log(range.padEnd(7), "→", row.join(" | "));
}

বাস্তব সিদ্ধান্ত — একটি payment SDK আপগ্রেড

“দোকান”-এ পেমেন্টের জন্য একটি কাল্পনিক package paysdk আছে, package.json-এ "paysdk": "^2.7.1", lockfile-এ 2.7.1. এ মাসে দুটি নতুন version এল:

• 2.8.0 — changelog: “নতুন: কিস্তিতে পেমেন্ট।” সীমার ভেতরে। কিন্তু lockfile আছে বলে কারও যন্ত্রে নিজে থেকে আসবে না — npm update paysdk চালালে আসবে। পেমেন্টের মতো সংবেদনশীল জায়গায় minor-ও টেস্ট চালিয়ে, তারপর merge.
• 3.0.0 — changelog: “charge() এখন Promise ফেরত দেয়; amount টাকার বদলে পয়সায় দিতে হবে।” এটি আসল breaking change: পুরোনো কোড charge(850) এখন ৮৫০ পয়সা, অর্থাৎ সাড়ে আট টাকা চার্জ করবে — কোনো error ছাড়াই! caret এটিকে আটকায়, ঠিক যেমন আটকানো উচিত। আপগ্রেড হবে আলাদা branch-এ: changelog আর migration guide পড়া, প্রতিটি charge খুঁজে বদলানো, টেস্ট, তারপর কিছু ব্যবহারকারীর কাছে আগে।

৫ · npx, global বনাম local, আর npm-এর ভাইবোনেরা

local install আর npx

npm install -g eslint দিলে টুলটি পুরো কম্পিউটারে একটি কপি হয়ে বসে — global install. কিন্তু দুটি প্রজেক্টে দুটি ভিন্ন ESLint version লাগলে? নতুন সহকর্মী জানবেন কীভাবে কোন version? তাই আধুনিক নিয়ম: প্রজেক্টের টুল প্রজেক্টের devDependencies-এ (local), আর সেগুলো চালানো হয় npm scripts দিয়ে বা npx দিয়ে। npx eslint src প্রথমে প্রজেক্টের node_modules/.bin-এ খোঁজে; না পেলে registry থেকে সাময়িকভাবে নামিয়ে চালায় — তার আগে জিজ্ঞেস করে Need to install the following packages: … Ok to proceed? (y). একবারের কাজে এটি দারুণ: npm create vite@latest আসলে create-vite package-টি এভাবেই চালায়। Node.js-এর নিজের version বদলাতে version manager (nvm, fnm, Volta) — পর্ব ৩-এ দেখেছেন।

npm, yarn, pnpm আর Bun

সবগুলো একই registry থেকে একই package নামায়; পার্থক্য কীভাবে নামায় আর সাজায়।

কোনটি বাছবেন? শেখার সময় npm-ই যথেষ্ট। দলে বা বড় monorepo-তে pnpm-এর কঠোরতা আর গতি অনেকে পছন্দ করেন। সবচেয়ে বড় নিয়ম অন্যটি: একটি প্রজেক্টে একটিই package manager. দুটি lockfile একসাথে থাকলে দুজন দুই রকম গাছ পাবেন — lockfile-এর পুরো উদ্দেশ্যই নষ্ট।

কোন package নেবেন — বাছাইয়ের প্রশ্ন

“তারিখ ফরম্যাট করতে একটা package বলো” — npm-এ খুঁজলে শতাধিক পাবেন। একটি package নেওয়া মানে বছরের পর বছর তার ভার বহন করা। নেওয়ার আগে পাঁচটি প্রশ্ন করুন:

1. সত্যিই লাগবে? Intl.DateTimeFormat (পর্ব ২০), structuredClone (পর্ব ১৯), fetch — একসময় এগুলোর জন্য package লাগত, এখন ভাষা বা ব্রাউজারেই আছে।
2. রক্ষণাবেক্ষণ চলছে? শেষ release কবে, issue-র উত্তর আসে কি না; “deprecated” লেখা থাকলে দূরে থাকুন।
3. কত মানুষ ব্যবহার করেন? সাপ্তাহিক download আর npm trends-এ তুলনা — বেশি চোখ মানে বাগ দ্রুত ধরা পড়ে।
4. আকার কত? ব্রাউজারে যা যাবে, তার প্রতিটি KB ব্যবহারকারীর মোবাইল ডেটা খরচ করে। bundlephobia-র মতো সাইট দেখায় package-টি বান্ডিলে কত বাড়াবে, আর tree-shaking হয় কি না। উদাহরণ: moment.js বড় আর ২০২০ থেকে রক্ষণাবেক্ষণ-মোডে — তার জায়গায় dayjs বা date-fns অনেক ছোট।
5. লাইসেন্স কী? license বলে আপনি কী করতে পারবেন। MIT, ISC, Apache-2.0, BSD — বাণিজ্যিক কাজেও সাধারণত নিরাপদ (কপিরাইট নোটিশ রাখতে হয়)। GPL বা AGPL হলে শর্ত অনেক কঠোর; কোম্পানির প্রজেক্টে আগে জিজ্ঞেস করুন।

৬ · নিরাপত্তা — প্রতিটি package একটি বিশ্বাসের সিদ্ধান্ত

পর্ব ৪৩-এ supply-chain attack-এর কথা শুনেছেন: আক্রমণকারী সরাসরি আপনার কোডে নয়, আপনি যার ওপর নির্ভর করেন সেখানে ক্ষতিকর কোড ঢোকায়। npm-এর জগতে পথগুলো খুব পরিচিত — আর প্রতিটির প্রতিরক্ষাও।

npm audit — জানা দুর্বলতার খোঁজ

npm audit আপনার lockfile-এর প্রতিটি package-এর version একটি নিরাপত্তা-ডেটাবেসের (GitHub Advisory Database) সাথে মেলায়। আসলে প্রতিটি npm install-এর শেষে এটি সংক্ষেপে চলে — “found 0 vulnerabilities” লাইনটি তারই ফল। দুর্বলতা পেলে রিপোর্ট দেখতে এমন:

# npm audit report   (নমুনা, সংক্ষেপিত)

nanoid  <3.3.8
Severity: moderate
Predictable results in nanoid generation when given non-integer values
fix available via `npm audit fix`
node_modules/nanoid

1 moderate severity vulnerability

রিপোর্ট পড়ার সময় জিজ্ঞেস করুন: দুর্বল package-টি কি ব্যবহারকারীর কাছে যায়, নাকি শুধু build টুলের গভীরে থাকে? দুর্বল function-টি কি আপনার কোডে আদৌ ডাকা হয়? npm audit fix সীমার ভেতরে ঠিক করে; --force major version বদলে দিতে পারে — সেটিও একটি আপগ্রেড, টেস্ট লাগবে। লক্ষ্য শূন্য সংখ্যা নয়, প্রতিটি সতর্কতা বোঝা।

দলের জন্য আরও তিনটি অভ্যাস

• স্বয়ংক্রিয় আপডেট PR: GitHub-এর Dependabot বা Renovate নতুন version পেলে নিজে থেকে pull request খোলে; CI টেস্ট চালায়, মানুষ রিভিউ করে। ছোট, নিয়মিত আপডেট সহজ; দুই বছরের জমানো আপডেট সবচেয়ে কঠিন।
• প্রকাশকের দিক থেকে: account-এ 2FA, আর CI থেকে provenance সহ প্রকাশ (npm publish --provenance বা trusted publishing) — npm পাতায় প্রমাণ থাকে package-টি কোন repository-র কোন commit থেকে তৈরি।
• নতুন version-এ একটু ধৈর্য: ক্ষতিকর version সাধারণত কয়েক ঘণ্টা থেকে কয়েক দিনে ধরা পড়ে সরানো হয়; প্রকাশের দিনই আপডেট না নেওয়া একটি সস্তা প্রতিরক্ষা।

৭ · Bundler কেন লাগে — আর Vite কীভাবে কাজ করে

পর্ব ৪৫-এ দেখেছেন, আধুনিক ব্রাউজার নিজেই ES module বোঝে — <script type="module"> দিলেই import চলে। তাহলে বান্ডিল কেন? একটি মাঝারি অ্যাপে নিজের ২০০টি module, node_modules থেকে আরও ১,৫০০টি। ব্রাউজার একটি ফাইল পড়ে তার import জানে, সেগুলো আনে, তারপর সেগুলোর import — শত শত অনুরোধের “জলপ্রপাত”, যা মোবাইল নেটওয়ার্কে পাতাকে কয়েক সেকেন্ড ধীর করে। তার ওপর import dayjs from "dayjs" — ব্রাউজার জানেই না “dayjs” কোন ফাইল (ঠিকানা ছাড়া নাম — bare specifier). Bundler এই কাজগুলো করে:

• জোড়া দেওয়া: entry ফাইল থেকে সব import অনুসরণ করে একটি গ্রাফ বানায়, তারপর অনেক module-কে কয়েকটি ফাইলে মেলায়; “dayjs”-এর মতো নামকে node_modules-এর আসল ফাইলে মেলায়।
• Tree-shaking: যে export কেউ import করেনি, তা বাদ (পর্ব ৪৫-এ দেখেছেন কেন এটি static import-এ সম্ভব)।
• Minification: ফাঁকা জায়গা, মন্তব্য বাদ, লম্বা নাম ছোট — calculateTotalPrice হয়ে যায় a. আসল কোডে ফেরত দেখতে source map.
• Code splitting: import("./admin.js")-এর মতো dynamic import আলাদা ফাইলে যায়, শুধু দরকার হলে নামে — অ্যাডমিন পাতার কোড সাধারণ ক্রেতার ব্রাউজারে আসে না।
• Content hash: ফাইলের নামে তার বিষয়বস্তুর hash — index-CAoPt-vL.js. বিষয়বস্তু বদলালে নাম বদলায়, তাই সার্ভার এই ফাইলগুলোকে এক বছরের জন্য cache করতে বলতে পারে (Cache-Control: max-age=31536000, immutable) — পর্ব ৪৪-এর caching কৌশলের ভিত্তি এটাই।
• আরও: CSS আর ছবি প্রক্রিয়া, পুরোনো ব্রাউজারের জন্য রূপান্তর, TypeScript বা JSX থেকে JavaScript.

Vite — ডেভেলপমেন্টে বান্ডিল ছাড়া, প্রোডাকশনে বান্ডিলসহ

পুরোনো bundler (webpack) ডেভেলপমেন্টেও প্রতিবার পুরো অ্যাপ বান্ডিল করত; বড় প্রজেক্টে সার্ভার চালু হতে মিনিট লাগত। Evan You (Vue-এর স্রষ্টা) ২০২০ সালে Vite (ফরাসি শব্দ, মানে “দ্রুত”) তৈরি করেন একটি সহজ পর্যবেক্ষণ থেকে: ব্রাউজার যখন নিজেই ES module বোঝে, ডেভেলপমেন্টে বান্ডিল করার দরকার কী? নিচের ডায়াগ্রামে একই প্রজেক্টের দুই মোড দেখুন:

“দোকান” প্রজেক্ট — ধাপে ধাপে

নিচের কমান্ডগুলো আমরা একটি খালি ফোল্ডারে চালিয়েছি (create-vite 9, Vite 8.3) — আউটপুট আসল, শুধু কিছু লাইন ছাঁটা। Vite 8-এর জন্য Node.js 20.19+ বা 22.12+ লাগে।

$ npm create vite@latest dokan -- --template vanilla
◇  Scaffolding project in /home/rafi/dokan...
└  Done. Now run:
  cd dokan
  npm install
  npm run dev

$ cd dokan && npm install
added 15 packages, and audited 16 packages in 3s
found 0 vulnerabilities

$ npm run dev
  VITE v8.3.4  ready in 128 ms
  ➜  Local:   http://localhost:5173/

$ npm run build
vite v8.3.4 building client environment for production...
✓ 9 modules transformed.
dist/index.html                  0.45 kB │ gzip: 0.29 kB
dist/assets/index-CsUDhMuy.css   4.10 kB │ gzip: 1.46 kB
dist/assets/index-CAoPt-vL.js    4.05 kB │ gzip: 1.77 kB
✓ built in 61ms

Environment variable — আর গোপন তথ্যের সতর্কতা

ডেভেলপমেন্টে API একটি ঠিকানায়, প্রোডাকশনে আরেকটিতে। Vite-এ এমন মান থাকে .env ফাইলে (.env.development, .env.production, আর শুধু নিজের যন্ত্রের জন্য Git-এ না রাখা .env.local), আর কোডে পড়া হয় import.meta.env দিয়ে:

// .env.production-এ লেখা:  VITE_API_URL=https://api.dokan.example
const base = import.meta.env.VITE_API_URL;
if (import.meta.env.DEV) console.log("ডেভেলপমেন্ট মোড, API:", base);

একটু ইতিহাস, আর Babel ও browserslist

পুরোনো ব্রাউজারের কথা ভাবতে হলে আসে Babel, একটি transpiler: নতুন syntax (যেমন ?.) পুরোনো ব্রাউজারের বোঝার মতো কোডে বদলায়। আর নতুন function (যেমন Array.prototype.at) পুরোনো ব্রাউজারে না থাকলে লাগে polyfill. কোন ব্রাউজার পর্যন্ত সমর্থন করবেন, তা অনেক টুল একই জায়গা থেকে পড়ে — browserslist, যেমন package.json-এ "browserslist": ["defaults"]. Vite-এর ডিফল্ট লক্ষ্য আধুনিক ব্রাউজার (Vite 7 থেকে “Baseline Widely Available”); খুব পুরোনো ব্রাউজারের জন্য @vitejs/plugin-legacy. Vite নিজে Babel নয়, দ্রুত native টুল ব্যবহার করে — Babel আজ বেশি দেখবেন পুরোনো প্রজেক্টে।

৮ · ESLint আর Prettier — বাগ ধরা, ফরম্যাট ঠিক করা, আর দলের কাজের ধারা

একটি linter আপনার কোড না চালিয়েই পড়ে (AST বানিয়ে) আর নিয়মভঙ্গ খোঁজে — যেমন একজন অভিজ্ঞ রিভিউয়ার, যিনি কখনো ক্লান্ত হন না। JavaScript-এ মূলধারার linter হলো ESLint (Nicholas C. Zakas, ২০১৩)। নিচের ফাংশনটি দেখুন — পড়তে ঠিকঠাক লাগে, কিন্তু এতে চারটি সমস্যা আছে। নিজে খুঁজে দেখুন, তারপর ESLint কী বলে মিলিয়ে নিন:

export function checkout(cart) {
  let price = cart.reduce((sum, item) => sum + item.price, 0);

  if (price = 0) {
    return "কার্ট খালি";
  }

  const discount = price > 5000 ? 0.1 : 0;

  return `মোট: ${totl} টাকা`;
}

$ npx eslint src
/home/rafi/dokan/src/cart.js
   2:7   error  The value assigned to 'price' is not used in subsequent statements  no-useless-assignment
   4:7   error  Expected a conditional expression and instead saw an assignment     no-cond-assign
   4:7   error  Unexpected constant condition                                       no-constant-condition
   8:9   error  'discount' is assigned a value but never used                       no-unused-vars
  10:18  error  'totl' is not defined                                               no-undef

✖ 5 problems (5 errors, 0 warnings)

Flat config — eslint.config.js

ESLint-এর নিয়ম ঠিক হয় একটি config ফাইলে। ESLint 9 (২০২৪) থেকে ডিফল্ট হলো flat config — eslint.config.js, একটি সাধারণ JavaScript module, যা config object-এর একটি array export করে। পরের object আগেরটির ওপর বসে। ESLint 10 (২০২৬) পুরোনো .eslintrc.json / .eslintrc.js ব্যবস্থা পুরোপুরি সরিয়ে দিয়েছে।

import js from "@eslint/js";
import globals from "globals";
import eslintConfigPrettier from "eslint-config-prettier";

export default [
  js.configs.recommended,                 // ESLint দলের বাছাই করা মূল নিয়ম
  {
    files: ["src/**/*.js"],
    languageOptions: { globals: globals.browser },  // window, document চেনা
    rules: { eqeqeq: "error" },           // == নিষেধ, === বাধ্যতামূলক
  },
  eslintConfigPrettier,                   // ফরম্যাটের নিয়ম বন্ধ — সেটা Prettier-এর কাজ
];

npx eslint . --fix দিলে যেসব নিয়মের নিরাপদ সমাধান যন্ত্র জানে, সেগুলো ESLint নিজে ঠিক করে দেয় — একে বলে autofix, যেমন prefer-const (বদলায় না এমন let-কে const বানানো)। কিন্তু if (price = 0) সে নিজে ঠিক করবে না — আপনি == চেয়েছিলেন নাকি সত্যিই মান বসাতে, তা শুধু আপনি জানেন। এডিটরে ESLint extension থাকলে এই লাল দাগ লেখার সময়ই দেখা যায়।

Prettier — ফরম্যাট নিয়ে আর তর্ক নয়

Tab না space? একক না দ্বৈত quote? শেষে comma? এসব প্রশ্নে কোনো দল কোনোদিন একমত হয়নি, আর কোড রিভিউয়ের অর্ধেক মন্তব্য এসবেই খরচ হতো। formatter Prettier (James Long, ২০১৭) একটি সাহসী সমাধান আনে: কোড পার্স করে পুরো ফাইল নিজের নিয়মে নতুন করে লেখে, আর অপশন রাখে খুব কম — ইচ্ছা করেই। তাই এটি “opinionated”. একটি এলোমেলো লেখা:

const cart={items:[ {name:'শার্ট',price:850},{name:"জুতা" ,price:1200}],total:function(){return this.items.reduce((s,i)=>s+i.price,0)}}
if(cart.total()==2050){console.log('ঠিক আছে')}

const cart = {
  items: [
    { name: "শার্ট", price: 850 },
    { name: "জুতা", price: 1200 },
  ],
  total: function () {
    return this.items.reduce((s, i) => s + i.price, 0);
  },
};
if (cart.total() == 2050) {
  console.log("ঠিক আছে");
}

ESLint-এর পুরোনো সংস্করণে indent, quote-এর মতো স্টাইলের নিয়মও ছিল, যা Prettier-এর সাথে লড়াই করত — একজন বদলায়, অন্যজন আপত্তি তোলে। eslint-config-prettier সেই নিয়মগুলো বন্ধ করে (উপরের config-এ শেষ লাইন)। ভাগাভাগিটা মনে রাখুন: ESLint = কোডের মান ও বাগ, Prettier = চেহারা। আরও দুটি নাম: Biome — Rust-এ লেখা, একাই lint আর format করে, অনেক দ্রুত; আর EditorConfig (.editorconfig) — indent, লাইনের শেষের মতো সাধারণ নিয়ম, যা প্রায় সব এডিটর বোঝে।

Git hook — ভুল কোড commit-এর আগেই থামানো

টুল থাকলেই হয় না; কেউ চালাতে ভুলে গেলে? Git hook হলো Git-এর নির্দিষ্ট মুহূর্তে (commit-এর আগে, push-এর আগে) নিজে থেকে চলা script. JavaScript প্রজেক্টে সাধারণ জুটি husky (hook বসায়, আর package.json-এ "prepare": "husky" script রাখে যাতে npm install-এর সময় সবার যন্ত্রে hook চালু হয়) আর lint-staged (শুধু এই commit-এ যুক্ত ফাইলগুলোর ওপর টুল চালায় — পুরো প্রজেক্টে নয়, তাই দ্রুত)।

"scripts": { "prepare": "husky" },
"lint-staged": {
  "*.js": ["eslint --fix", "prettier --write"],
  "*.{css,md,json}": "prettier --write"
}

$ git add src/cart.js
$ git commit -m "কার্টে ছাড় যোগ"

npx lint-staged

✔ Preparing lint-staged...
❯ Running tasks for staged files...
  ❯ *.js — 1 file      (src/cart.js; ui.js stage হয়নি, তাই বাদ)

✖ eslint --fix:
  10:18  error  'totl' is not defined  no-undef

husky - pre-commit script failed (code 1)
→ totl ঠিক করে আবার git add + git commit
→ এবার সব সবুজ: commit তৈরি হলো

একটি দলের দৈনন্দিন কাজের ধারা

সব মিলিয়ে একটি দলের দিন: (১) git clone, তারপর npm ci — হুবহু একই গাছ, husky চালু। (২) npm run dev — HMR, এডিটরে ESLint-এর দাগ, সেভে Prettier. (৩) git commit — hook staged ফাইলে lint আর format চালায়। (৪) pull request খুললে CI (যেমন GitHub Actions) পরিষ্কার যন্ত্রে npm ci, lint, test (পর্ব ৪৮) আর build চালায় — একটিও ব্যর্থ হলে merge বন্ধ। (৫) merge হলে dist/ deploy. “আমার যন্ত্রে তো চলে!” বলার জায়গা নেই — সবখানে একই lockfile, একই config, একই কমান্ড।

৯ · AI-এর যুগে — পুরোনো টুল, ভারী package আর বানানো নাম

“একটা React প্রজেক্ট সেটআপ করে দাও” বা “তারিখ ফরম্যাটের জন্য কী ইনস্টল করব?” — AI এসব প্রশ্নে চটজলদি উত্তর দেয়। কিন্তু টুলিং এমন একটি জায়গা, যেখানে তথ্য দ্রুত পুরোনো হয়, আর AI-এর শেখা ডেটা প্রায়ই পুরোনো বছরের টিউটোরিয়ালে ভরা। ভুলগুলো তাই খুব নির্দিষ্ট ধরনের:

AI-এর সাজানো প্রজেক্ট হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি package-নাম npm পাতায় খুলে দেখেছি — বানান হুবহু, বহুদিনের পুরোনো, যথেষ্ট download, আসল repository-র লিংক আছে
• প্রতিটি dependency সত্যিই লাগে; ভাষা বা ব্রাউজারের নিজস্ব সুবিধায় হয় এমন কিছু package দিয়ে করা হয়নি
• dependencies আর devDependencies সঠিক ভাগে; package-lock.json তৈরি হয়েছে আর commit হবে
• config আধুনিক: eslint.config.js, কোনো .eslintrc বা create-react-app-এর চিহ্ন নেই
• npm audit চালিয়ে প্রতিটি সতর্কতা বুঝেছি; --force বা --legacy-peer-deps চোখ বন্ধ করে দিইনি
• dist/-এর JS ফাইলে খুঁজে দেখেছি কোনো গোপন চাবি বা পাসওয়ার্ড নেই