TypeScript ফুল-স্ট্যাকের জন্য — type, interface, generic আর ভাগ করা type

১ · এক মাপ, দুই পাশ — type কেন দুই দিকেই লাভ দেয়

একজন দর্জির দোকান ভাবুন। সামনের কাউন্টারে কর্মচারী মাপ লেখেন, পেছনে কারিগর কাপড় কাটেন। কর্মচারী যদি ইঞ্চিতে লেখেন আর কারিগর সেন্টিমিটার ভাবেন, জামা নষ্ট হবে। ভুলটি ধরা পড়বে ক্রেতা জামা পরার পরে। সমাধান সহজ: দুজনে একই ছাপানো মাপের খাতা ব্যবহার করবেন।

ওয়েব অ্যাপেও একই ঘটনা। Browser-এর কোড হলো কাউন্টার, server-এর কোড হলো কারিগর, আর তাদের মাঝে যায় JSON. দুই পাশে যদি দাম নিয়ে দুই রকম ধারণা থাকে, ভুলটি ধরা পড়ে ব্যবহারকারীর সামনে। TypeScript-এ লেখা একটি ভাগ করা type হলো সেই ছাপানো মাপের খাতা।

এক লাইনে মনে করিয়ে দিই: TypeScript কোড চালানোর আগে একটি type checker সব type মিলিয়ে দেখে, তারপর type মুছে সাধারণ JavaScript বানায়। এবার একটি বাস্তব পরীক্ষা দেখা যাক। কোর্সের চলমান উদাহরণ “বাজারঘর” একটি কাল্পনিক অনলাইন দোকান। তার ছোট একটি project-এ shared/product.ts ফাইলে Product type আছে। সেটি ব্যবহার করে একটি server ফাইল আর একটি React ফাইল। এখন price ঘরের নাম বদলে priceTaka করা হলো।

সত্যিকারের run · লেখার সময়ে TypeScript 7.0.2 · ~/bazarghar

$ npx tsc
client/ProductCard.tsx(4,38): error TS2339: Property 'price' does not exist on type 'Product'.
server/products.ts(4,45): error TS2339: Property 'price' does not exist on type 'Product'.

একটি বদল, দুটি লাল দাগ, দুই আলাদা জগতে। Compiler কোনো request পাঠায়নি, কোনো server চালায়নি। শুধু কোড পড়ে বলেছে, frontend-এর ৪ নম্বর লাইন আর backend-এর ৪ নম্বর লাইন এখন পুরোনো নাম ধরে আছে। Type ছাড়া এই ভুল দেখা যেত পরে, হয়তো পণ্যের কার্ডে “undefined টাকা” হিসেবে।

ছবির দাগটিই এই পর্বের সবচেয়ে বড় কথা। দাগের ওপরে TypeScript অসাধারণ পাহারাদার। দাগের নিচে তার কোনো অস্তিত্ব নেই। পুরো পর্ব জুড়ে আমরা এই দুই ভাগ আলাদা করে দেখব।

২ · Inference, union, literal আর narrowing

সব জায়গায় type লিখতে হয় না। Type inference মানে compiler মান দেখে নিজেই type বুঝে নেয়। অভ্যাসটি হলো: function-এর parameter আর ডেটার আকার আপনি লিখবেন, ভেতরের ছোট ভ্যারিয়েবল compiler-এর হাতে ছেড়ে দেবেন। নিচের প্রতিটি মন্তব্যে compiler-এর বের করা type লেখা আছে।

const city = "dhaka";         // type: "dhaka"   (const বদলাবে না)
let area = "dhaka";           // type: string    (let বদলাতে পারে)
const prices = [500, 140];    // type: number[]

type OrderStatus = "pending" | "paid" | "shipped";
type Id = number | string;

"dhaka" যখন নিজেই একটি type হয়, তাকে বলে literal type. আর | চিহ্ন দিয়ে জোড়া type হলো union type: “এগুলোর যেকোনো একটি”। ফুল-স্ট্যাক কাজে OrderStatus-এর মতো union খুব কাজের। ডেটাবেসে থাকা নির্দিষ্ট কয়েকটি অবস্থার বাইরে কিছু লিখলেই compiler ধরবে, যেমন "payed" বানান ভুল।

Union-এর মান সরাসরি ব্যবহার করা যায় না, কারণ compiler জানে না এখন কোন রূপ। যাচাই করলে সে শাখা ধরে ধরে type সরু করে আনে। একেই বলে narrowing. নিচের ডায়াগ্রামে compiler কোড চালাচ্ছে না, শুধু পড়ছে। প্রতিটি ধাপে v-এর type দেখুন।

1function priceText(v: number | string | null) {2  if (v === null) {3    return "দাম জানা নেই";4  }5  if (typeof v === "string") {6    return v.trim();7  }8  return v.toFixed(2);9}

Narrowing হয় typeof, ===, instanceof, in আর সত্য-মিথ্যা যাচাই দেখে। মনে রাখার বিষয়: এগুলো সাধারণ JavaScript যাচাই, চলার সময়ও সত্যিই চলে। তাই narrowing নিরাপদ, আর পরের অংশে দেখা as নিরাপদ নয়।

৩ · Discriminated union — API-র ফল সৎভাবে লেখা

কুরিয়ারের স্লিপ ভাবুন। “পৌঁছেছে” লেখা স্লিপে থাকে গ্রহীতার সই। “ঠিকানা ভুল” স্লিপে থাকে কোন অংশ ভুল। “গুদামে আটকে আছে” স্লিপে থাকে কারণ। ওপরের ছাপানো ঘরটি দেখেই কর্মচারী বোঝেন, নিচে কোন তথ্য খুঁজতে হবে।

নতুনদের API-র ফল প্রায়ই সব ঘর একসাথে রাখা একটি বস্তার মতো হয়:

type BadResult = {
  loading: boolean;
  data?: Product;
  error?: string;
};

একটু হিসাব করি। তিনটি ঘরের প্রতিটি থাকতে বা না থাকতে পারে, তাই সম্ভাব্য মিশ্রণ ২ × ২ × ২ = ৮টি। অথচ বাস্তবে বৈধ অবস্থা মাত্র ৩টি: লোড হচ্ছে, ডেটা এসেছে, ভুল হয়েছে। বাকি ৫টি অসম্ভব অবস্থা (যেমন একই সাথে ডেটা আর ভুল), কিন্তু type সেগুলো আটকায় না। ফলে প্রতিটি জায়গায় data আছে কি না, নিজে মনে রেখে যাচাই করতে হয়।

Discriminated union এই বস্তাকে আলাদা আলাদা স্লিপে ভাগ করে। প্রতিটি রূপে একই নামের একটি literal ঘর থাকে (এখানে kind). সেই ঘর দেখেই compiler বাকি ঘরগুলো চিনে নেয়। default শাখার never হলো exhaustiveness check: সব রূপ সামলানো হলে সেখানে কিছুই বাকি থাকে না। নিচের ব্লকটি চালিয়ে দেখুন।

type Product = { id: number; name: string; price: number };

type ApiResult<T> =
  | { kind: "ok"; data: T }
  | { kind: "invalid"; fields: string[] }
  | { kind: "error"; status: number; message: string };

function show(r: ApiResult<Product>): string {
  switch (r.kind) {
    case "ok":
      return `${r.data.name}: ${r.data.price} টাকা`;
    case "invalid":
      return `ফর্মে ভুল: ${r.fields.join(", ")}`;
    case "error":
      return `সার্ভারের ভুল ${r.status}: ${r.message}`;
    default: {
      const unreachable: never = r;
      return unreachable;
    }
  }
}

const results: ApiResult<Product>[] = [
  { kind: "ok", data: { id: 7, name: "চিনিগুঁড়া চাল", price: 500 } },
  { kind: "invalid", fields: ["price", "stock"] },
  { kind: "error", status: 503, message: "ডেটাবেস ব্যস্ত" },
];

for (const r of results) console.log(show(r));

চিনিগুঁড়া চাল: 500 টাকা
ফর্মে ভুল: price, stock
সার্ভারের ভুল 503: ডেটাবেস ব্যস্ত

এবার ইচ্ছা করেই তিনটি ভুল করা যাক। নিচের ব্লকটি compile হবে না, আর সেটিই উদ্দেশ্য। এই পাতার কোড ব্লকগুলো চলে TypeScript 5.6-এ, --strict সহ। চালিয়ে compiler-এর আসল বার্তা দেখুন।

type Product = { id: number; name: string; price: number };
type ApiResult<T> =
  | { kind: "ok"; data: T }
  | { kind: "invalid"; fields: string[] }
  | { kind: "error"; status: number; message: string };

function showName(r: ApiResult<Product>): string {
  return r.data.name;
}

function label(r: ApiResult<Product>): string {
  switch (r.kind) {
    case "ok":
      return "পাওয়া গেছে";
    case "invalid":
      return "ফর্মে ভুল";
    default: {
      const unreachable: never = r;
      return unreachable;
    }
  }
}

const body: unknown = JSON.parse('{"price":500}');
console.log(body.price + 60);

prog.ts(8,12): error TS2339: Property 'data' does not exist on type 'ApiResult<Product>'.
  Property 'data' does not exist on type '{ kind: "invalid"; fields: string[]; }'.
prog.ts(18,13): error TS2322: Type '{ kind: "error"; status: number; message: string; }' is not assignable to type 'never'.
prog.ts(25,13): error TS18046: 'body' is of type 'unknown'.

৪ · interface বনাম type, আর optional বনাম nullable

interface আর type alias নিয়ে অনলাইনে অনেক তর্ক দেখবেন। বাস্তবে object-এর আকার লিখতে দুটোই প্রায় একই কাজ করে। পার্থক্য কয়েকটি জায়গায়:

কোনটি সেরা, তা নিয়ে সমাজে একমত নেই। কেউ object-এ সবসময় interface লেখেন, কেউ সবখানে type. দুই পথই ঠিক। আসল কথা, দলে একটি নিয়ম মেনে চলা। এই কোর্সে আমরা type লিখব, কারণ API-র ফল প্রায়ই union হয়।

“নেই”, “undefined” আর “null” — তিন আলাদা কথা

ফুল-স্ট্যাকে এই পার্থক্য খুব জরুরি, কারণ ডেটা JSON হয়ে যাতায়াত করে। Optional property (note?: string) মানে ঘরটি না থাকলেও চলে। আর note: string | null মানে ঘরটি থাকবেই, তবে মান ফাঁকা হতে পারে। JSON-এ এদের আচরণও আলাদা: JSON.stringify({ a: undefined, b: null }) দেয় {"b":null}. অর্থাৎ undefined ঘরটি পথেই হারিয়ে যায়, null পৌঁছায়।

এই সব পার্থক্য কাজ করে strictNullChecks চালু থাকলে। এটি বন্ধ থাকলে null আর undefined সব type-এর ভেতরে লুকিয়ে ঢুকে পড়ে। Array.find কিছু না পেলে undefined দেয়। একই ফাইলে option বন্ধ আর চালু, দুই অবস্থায় চালিয়ে দেখা যাক।

type Product = { id: number; name: string };
const products: Product[] = [{ id: 1, name: "চা পাতা" }];
const found = products.find((p) => p.id === 99);
console.log(found.name);

সত্যিকারের run · TypeScript 7.0.2, Node.js 24.15

$ npx tsc --ignoreConfig --noEmit --strictNullChecks false find.ts
(কোনো error নেই)

$ node find.ts
TypeError: Cannot read properties of undefined (reading 'name')
…

$ npx tsc --ignoreConfig --noEmit find.ts
find.ts(4,13): error TS18048: 'found' is possibly 'undefined'.

Option বন্ধ থাকলে compiler চুপ, আর প্রোগ্রাম ভেঙে পড়ে। চালু থাকলে একই ভুল চালানোর আগেই ধরা পড়ে। শেষ কমান্ডে আলাদা করে strict লিখতে হয়নি, কারণ TypeScript 6.0 থেকে এটি নিজে থেকেই চালু। ঠিক করার উপায় হলো যাচাই: if (found) console.log(found.name);. found!.name লিখলে error মুছবে, কিন্তু ভুল থেকে যাবে।

৫ · Generic — type হারায় না এমন API function

মুদি দোকানের কৌটা ভাবুন। কৌটা একই মাপের, কিন্তু গায়ে লেবেল থাকে “চিনি” বা “ডাল”। লেবেল দেখেই বোঝা যায় ভেতরে কী আছে, না খুলেই। Generic হলো type-এর সেই লেবেল। ApiResult<T> কৌটা একটাই, T হলো লেবেলের ফাঁকা জায়গা।

Generic ছাড়া fetchJson লিখলে ফেরত আসবে any, কারণ await res.json() নিজেই any দেয়। তখন r.data.pirce বানান ভুল করলেও কেউ ধরবে না। Generic থাকলে type ঢোকে এক দিক দিয়ে, বের হয় আরেক দিক দিয়ে। নিচের ডায়াগ্রামে দেখুন T কীভাবে function পার হয়। এখানেও compiler কোড চালায় না।

1async function fetchJson<T>(2  path: string, check: (x: unknown) => T3): Promise<ApiResult<T>> { … }45const r = await fetchJson(path, toProduct);6if (r.kind === "ok") console.log(r.data.price);

নিচের ব্লকে network নেই। toyServer একটি ছোট Map, যা server-এর জায়গায় JSON লেখা ফেরত দেয়। খেয়াল করুন, দ্বিতীয় পণ্যে price ভুল করে লেখা হয়ে এসেছে "140". check function-টি হলো পাহারাদার।

type Product = { id: number; name: string; price: number };
type ApiResult<T> =
  | { kind: "ok"; data: T }
  | { kind: "error"; status: number; message: string };
const toyServer = new Map<string, string>([
  ["/api/products/7", '{"id":7,"name":"চিনিগুঁড়া চাল","price":500}'],
  ["/api/products/8", '{"id":8,"name":"মসুর ডাল","price":"140"}'],
]);
async function fetchJson<T>(path: string, check: (x: unknown) => T): Promise<ApiResult<T>> {
  const text = toyServer.get(path);
  if (text === undefined) return { kind: "error", status: 404, message: "পাওয়া যায়নি" };
  const raw: unknown = JSON.parse(text);
  try {
    return { kind: "ok", data: check(raw) };
  } catch (e) {
    return { kind: "error", status: 502, message: e instanceof Error ? e.message : "অজানা ভুল" };
  }
}
function toProduct(x: unknown): Product {
  const o = x as Partial<Record<keyof Product, unknown>>;
  if (typeof o?.id !== "number" || typeof o.name !== "string" || typeof o.price !== "number") {
    throw new Error("Product-এর আকার মেলেনি");
  }
  return { id: o.id, name: o.name, price: o.price };
}

async function main() {
  for (const path of ["/api/products/7", "/api/products/8", "/api/products/9"]) {
    const r = await fetchJson(path, toProduct);
    if (r.kind === "ok") console.log("পেলাম:", r.data.name, r.data.price + 60);
    else console.log("ব্যর্থ:", r.status, r.message);
  }
}

main();

পেলাম: চিনিগুঁড়া চাল 560
ব্যর্থ: 502 Product-এর আকার মেলেনি
ব্যর্থ: 404 পাওয়া যায়নি

৬ · Utility type — এক Product থেকে অনেক আকার

একটি Product-এর চেহারা জায়গা ভেদে বদলায়। নতুন পণ্য বানানোর সময় id থাকে না, কারণ সেটি দেয় ডেটাবেস। PATCH-এ যেকোনো একটি ঘর আসতে পারে। ক্রেতাকে কেনা দাম দেখানো যাবে না। প্রতিটির জন্য আলাদা type হাতে লিখলে একই তথ্য চার জায়গায় থাকবে, আর একদিন মিল হারাবে। Utility type একটি মূল type থেকে বাকিগুলো বানিয়ে দেয়।

type Product = { id: number; name: string; price: number; stock: number; costPrice: number };

type NewProduct = Omit<Product, "id">;              // POST-এর body: id দেয় database
type ProductPatch = Partial<NewProduct>;            // PATCH-এর body: যেকোনো ঘর
type CardView = Pick<Product, "name" | "price">;    // কার্ডে শুধু এ দুটি
type PublicProduct = Omit<Product, "costPrice">;    // ক্রেতার জন্য
type StockByCity = Record<"dhaka" | "sylhet", number>;

const db: Product = { id: 7, name: "মসুর ডাল", price: 140, stock: 12, costPrice: 110 };

const created: NewProduct = { name: "চা পাতা", price: 90, stock: 5, costPrice: 70 };
const patch: ProductPatch = { price: 150 };
const updated: Product = { ...db, ...patch };
const card: CardView = { name: updated.name, price: updated.price };
const stock: StockByCity = { dhaka: 12, sylhet: 0 };

console.log(created.name, updated.price, card, stock.dhaka + stock.sylhet);

// ফাঁদ: Omit শুধু type থেকে বাদ দেয়, মান থেকে নয়
function leaky(p: Product): PublicProduct {
  return p;
}
function safe(p: Product): PublicProduct {
  const { costPrice, ...rest } = p;
  return rest;
}

console.log(JSON.stringify(leaky(db)));
console.log(JSON.stringify(safe(db)));

চা পাতা 150 { name: 'মসুর ডাল', price: 150 } 12
{"id":7,"name":"মসুর ডাল","price":140,"stock":12,"costPrice":110}
{"id":7,"name":"মসুর ডাল","price":140,"stock":12}

৭ · React-এ props আর event — এক ঝলক

React শুরু হবে পর্ব ০৭ থেকে, props আসবে পর্ব ০৯-এ, আর event পর্ব ১০-এ। এখন শুধু দেখে রাখুন TypeScript সেখানে কী রূপে থাকে। একটি component আসলে function, আর props তার argument. তাই props-এর type লেখা হয় সাধারণ object type-এর মতোই।

import { useState } from "react";

type AddToCartProps = {
  productId: number;
  maxQty: number;
  onAdd: (id: number, qty: number) => void;
};

export function AddToCart({ productId, maxQty, onAdd }: AddToCartProps) {
  const [qty, setQty] = useState(1);        // inference: number

  function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    setQty(Number(e.currentTarget.value));  // input-এর value সবসময় string
  }

  return (
    <div>
      <input type="number" max={maxQty} value={qty} onChange={handleChange} />
      <button onClick={() => onAdd(productId, qty)}>কার্টে যোগ করুন</button>
    </div>
  );
}

এখানে তিনটি জিনিস খেয়াল করার মতো। useState(1) নিজেই বুঝে নিয়েছে state একটি number. Event handler আলাদা function হলে তার type হাতে লিখতে হয়, যেমন React.ChangeEvent<HTMLInputElement>. আর inline onClick={() => …}-এ কিছু লিখতে হয় না, compiler জায়গা দেখেই বোঝে। এবার component-টি ভুল prop দিয়ে ব্যবহার করে দেখা যাক: <AddToCart productId="7" maxQty={5} onAdd={() => {}} />.

সত্যিকারের run · TypeScript 7.0.2, @types/react 19.3 · শুধু type যাচাই

$ npx tsc
client/AddToCart.tsx(24,32): error TS2322: Type 'string' is not assignable to type 'number'.

লাইন ২৪-এ ভুল ধরা পড়েছে, চলার আগেই। React-এর ক্ষেত্রে এটি অনেক সময় বাঁচায়, কারণ একটি prop-এর নাম বদলালে যতগুলো জায়গায় component ব্যবহার হয়েছে, সব এক তালিকায় চলে আসে।

৮ · Type মুছে যায় — তাই বাইরের ডেটা যাচাই করতেই হবে

ছবি ৬.১-এর দাগের নিচে এবার নামা যাক। Type erasure মানে build-এর সময় সব type মুছে ফেলা। নিচের ফাইলে server থেকে আসা JSON-এ দাম একটি লেখা। কোড as দিয়ে compiler-কে বলছে, “এটি Product, মেনে নিন।” (JSON.parse নিজে any দেয়, তাই compiler আপত্তি করে না।)

type Product = { name: string; price: number };

function withDelivery(p: Product, delivery: number): number {
  return p.price + delivery;
}

const body = '{"name":"চাল","price":"500"}';
const product = JSON.parse(body) as Product;
console.log(withDelivery(product, 60));

সত্যিকারের run · TypeScript 7.0.2 · cart.js হলো tsc-এর লেখা ফাইল

$ npx tsc --ignoreConfig --target es2023 --module esnext --outDir out cart.ts
(কোনো error নেই)

$ cat out/cart.js
"use strict";
function withDelivery(p, delivery) {
    return p.price + delivery;
}
const body = '{"name":"চাল","price":"500"}';
const product = JSON.parse(body);
console.log(withDelivery(product, 60));

$ node out/cart.js
50060

Compiler খুশি, প্রোগ্রাম চলেছে, আর ৫৬০ টাকার বদলে বিল ৫০০৬০ টাকা। ফলাফলের ঘোষিত type number, অথচ আসল মান একটি string. Type আর বাস্তবের এই ফাঁকেই আসল বাগ জন্মায়। Compile করা ফাইলে Product, number, as, কিছুই নেই। চলার সময় পরীক্ষা করার মতো কিছু আর বাকি থাকে না।

unknown বনাম any

একটি schema, দুটি জিনিস

অংশ ৫-এর toProduct-এর মতো যাচাই হাতে লেখা যায়, কিন্তু type আর যাচাই আলাদা থাকলে একদিন মিল হারায়। Schema library এই দ্বৈততা সরিয়ে দেয়। Zod-এ আপনি একবার নিয়ম লেখেন, আর তা থেকেই চলার সময়ের যাচাই আর build-এর সময়ের type দুটোই পান। Route-এর সাথে পুরো ব্যবহার আসবে পর্ব ২৭-এ, আর form-এ দুই দিকের ব্যবহার পর্ব ২১-এ। এখানে শুধু মূল ধারণাটি দেখুন।

import * as z from "zod";

export const ProductInput = z.object({
  name: z.string().min(2),
  price: z.number().positive(),
  stock: z.int().min(0),
});

export type ProductInput = z.infer<typeof ProductInput>;

import { ProductInput } from "../shared/product-schema.ts";

function handle(body: unknown) {
  const result = ProductInput.safeParse(body);
  if (!result.success) {
    return { status: 400, issues: result.error.issues.map((i) => `${i.path.join(".")}: ${i.code}`) };
  }
  const product: ProductInput = result.data;
  return { status: 201, total: product.price * 2 };
}

console.log(handle({ name: "চিনিগুঁড়া চাল", price: 500, stock: 12 }));
console.log(handle({ name: "চিনিগুঁড়া চাল", price: "500", stock: -1 }));

সত্যিকারের run · লেখার সময়ে Zod 4.6.7, Node.js 24.15

$ npx tsc
(কোনো error নেই)

$ node server/create-product.ts
{ status: 201, total: 1000 }
{ status: 400, issues: [ 'price: invalid_type', 'stock: too_small' ] }

এখানে Node.js 24.15 নিজেই .ts ফাইল থেকে type মুছে চালিয়েছে। মনে রাখবেন, সে type যাচাই করে না, সেই কাজ আগের tsc কমান্ডের। নিচের ডায়াগ্রামে একই schema-র পুরো যাত্রা দেখুন।

const ProductInput = z.object({
  name: z.string().min(2),
  price: z.number().positive(),
  stock: z.int().min(0),
});

{
  name: string;
  price: number;
  stock: number;
}
// positive() বা min(0) type-এ নেই, ওগুলো চলার সময়ের নিয়ম

// type ProductInput = … উধাও
const ProductInput = z.object({ … });  // সাধারণ JavaScript মান, রয়ে গেছে

safeParse(...)  →  success: true
{ status: 201, total: 1000 }

safeParse(...)  →  success: false
{ status: 400, issues: [
  'price: invalid_type',
  'stock: too_small' ] }

যাচাইয়ের দাম — byte-এ হিসাব

Type নিজে এক byte-ও পাঠায় না। কিন্তু schema চলার সময়ের কোড, তাই browser-এ পাঠালে তার দাম আছে। একই নিয়ম নিয়ে esbuild 0.28 দিয়ে ছোট ছোট bundle বানিয়ে মাপা হয়েছে (minified, gzip -9).

এগুলো একটি ছোট নমুনায় একবারের স্থানীয় মাপ, সাধারণ ফলাফল নয়। Bundler আর version বদলালে সংখ্যাও বদলাবে। তবু দুটি শিক্ষা আছে। প্রথমত, type-only ফাইল আর সাধারণ JavaScript ফাইলের minified আকার হুবহু সমান, 202 B: type সত্যিই শূন্য খরচের। দ্বিতীয়ত, import লেখার ধরনেও আকার অনেক বদলাতে পারে। ধরে নিই ব্যবহারকারীর গতি ১ Mbps: 27,050 × 8 ÷ 1,000,000 ≈ 0.22 s, আর 6,203 B-তে ≈ 0.05 s. Server-এ এই খরচ প্রায় গুরুত্বহীন, browser-এ ভাবতে হয়। Bundle মাপার পুরো পদ্ধতি আসবে পর্ব ৭৯-এ।

৯ · বাজারঘরে ভাগ করা type, tsconfig আর TypeScript 7

এতক্ষণের ছোট project-এর গঠন ছিল এমন। client আর server কেউ কারও ফাইল import করে না, দুজনেই import করে shared থেকে।

bazarghar/
├── shared/    Product type, ProductInput schema
├── server/    API কোড
├── client/    React কোড
├── package.json
└── tsconfig.json

শুধু type আনতে import type { Product } from "…" লিখুন। এতে নিশ্চিত হয় যে build-এর পরে ওই import পুরোপুরি মুছে যাবে, কোনো server কোড browser-এ যাবে না। বড় project-এ shared সাধারণত npm workspace-এর আলাদা package হয়। আর দুটি সীমা মনে রাখুন। প্রথমত, ভাগ করা type মেলে শুধু এক repository-র ভেতরে, মোবাইল অ্যাপ বা অন্য দলের জন্য চুক্তি লাগে (পর্ব ৩৫-এ OpenAPI, পর্ব ৩৭-এ tRPC). দ্বিতীয়ত, ব্যবহারকারীর browser-এ পুরোনো কোড খোলা থাকতে পারে, আর server নতুন। Type সেই ফাঁক দেখে না।

tsconfig-এর যে option-গুলো কাজে লাগে

tsconfig.json হলো যাচাই কতটা কড়া হবে তার নিয়ম। ওপরের সব run এই ফাইল দিয়েই হয়েছে। Project তৈরির সাধারণ পরিবেশ আছে পর্ব ০৫-এ।

{
  "compilerOptions": {
    "target": "es2023",
    "module": "nodenext",
    "lib": ["es2023", "dom"],
    "jsx": "react-jsx",
    "types": ["node", "react"],
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "allowImportingTsExtensions": true,
    "noEmit": true
  },
  "include": ["shared", "server", "client"]
}

TypeScript 6.0 থেকে strict নিজে থেকেই চালু, আর types-এর ডিফল্ট ফাঁকা তালিকা। তাই @types প্যাকেজ এখন নিজে থেকে যুক্ত হয় না, এখানে types তালিকায় লিখতে হয়েছে। তবু "strict": true লিখে রাখা ভালো, কারণ পুরোনো version বা অন্য টুলও একই ফাইল পড়তে পারে।

TypeScript 7 — নতুন compiler

লেখার সময়ে npm-এ typescript-এর latest version 7.0.2, আর এই পর্বের স্থানীয় run সেটিতেই হয়েছে। Microsoft-এর ঘোষণা অনুযায়ী ২০২৬ সালের জুলাইয়ে 7.0 এসেছে, যা compiler-কে Go ভাষায় নতুন করে লেখা (native port). প্যাকেজের নাম আর tsc কমান্ড একই আছে। ঘোষণায় বড় project-এ সাধারণত ৮ থেকে ১২ গুণ দ্রুত full build-এর দাবি করা হয়েছে। এটি Microsoft-এর নিজের মাপ।

সত্যিকারের run · নিজে বানানো ৪,০০০ ফাইলের নমুনা project · tsc -p . তিনবার করে

হিসাব: ৮২৫২ ÷ ১৬৪৮ ≈ ৫ গুণ। এটি একটি কম্পিউটারে একটি কৃত্রিম project-এর মাপ, সাধারণ ফলাফল নয়। ছোট project-এ পার্থক্য কম চোখে পড়বে। আরও মনে রাখুন, 7.0 কিছু পুরোনো option সরিয়ে দিয়েছে (যেমন target: es5, moduleResolution: node10, baseUrl), আর ঘোষণা অনুযায়ী এটি এখনো আগের মতো programmatic API দেয় না। তাই কিছু টুল কিছুদিন 6.0-র ওপর নির্ভর করতে পারে। আপগ্রেডের আগে নিজের টুলের docs দেখে নিন। এই পাতার চালানো যায় এমন ব্লকগুলো এখনো 5.6-এ চলে, তবে এখানে দেখানো ভাষার বিষয়গুলো দুই version-এই একই ফল দিয়েছে।

১০ · AI-এর যুগে — লাল দাগ মোছা আর ভুল মোছা এক নয়

AI TypeScript খুব দ্রুত লেখে, আর তার কোড প্রায়ই compile-ও হয়। সমস্যা হলো, “compile হয়েছে” মানে সব প্রমাণিত নয়। Error সরাতে AI-এর সবচেয়ে সহজ পথ হলো compiler-কে চুপ করানো। আপনি যদি এই পর্বের দাগটি মনে রাখেন, তার কৌশলগুলো সহজেই ধরতে পারবেন।

AI-এর TypeScript হাতে পেলে — চেকলিস্ট

• npx tsc নিজে চালিয়েছি, আর error শূন্য
• Diff-এ নতুন any, as, !, @ts-ignore খুঁজেছি, প্রতিটির কারণ জানি
• tsconfig-এ কোনো option দুর্বল করা হয়নি
• Server-এ আসা প্রতিটি ইনপুট চলার সময় যাচাই হয়, ভুল আকারের ডেটা দিয়ে পরীক্ষা করেছি
• API-র আসল JSON উত্তর পড়েছি, কোনো গোপন ঘর নেই
• নতুন package থাকলে তার docs আর version নিজে দেখেছি, আর কোনো secret AI-কে দিইনি