تطبيق: مسار البناء
Build Flow Walkthrough
تطبيق: مسار البناء — Build Flow Walkthrough
مسار البناء في TypeScript له فكرتان: فحص الأنواع، وإنتاج JavaScript. في بعض المشاريع تفعل الاثنين بـtsc. في مشاريع أخرى، أداة مثل Vite أو esbuild تنتج الملفات، وtsc --noEmit يفحص الأنواع فقط. لا تحتاج حفظ كل أداة الآن؛ افهم الفصل بين الفحص والتشغيل.
خطوة جيدة لأي مشروع: فحص الأنواع قبل النشر. لأن TypeScript قيمتها الأساسية أن توقف الخطأ قبل runtime. إذا تجاهلت أخطاء compiler ثم نشرت، فقد فقدت جزءاً كبيراً من فائدتها.
تمثيل خطوات البناء
هذا ليس تنفيذ بناء، بل نموذج ذهني: typecheck ثم test ثم bundle.
البناء التزايدي — Incremental Build
البناء الكامل بطيء في المشاريع الكبيرة. TypeScript يدعم incremental: true في tsconfig: يحفظ معلومات آخر build في ملف .tsbuildinfo ويُعيد فحص الملفات المتغيرة فقط:
{
"compilerOptions": {
"incremental": true,
"tsBuildInfoFile": ".tsbuildinfo"
}
}
Project References و tsc -b
للمشاريع متعددة الوحدات (monorepo)، تستخدم project references: كل حزمة لها tsconfig.json وتُشير لبعضها. ثم تبني الكل بأمر واحد:
tsc -b # يبني كل المشاريع المُشار إليها بالترتيب الصحيح
tsc -b --watch # وضع المراقبة المستمرة
tsc -b --clean # حذف الناتج المبني
tsc -b ذكي: يبني فقط الوحدات التي تغيرت. لا تحتاج project references في المشاريع الصغيرة، لكن معرفتها مهمة عند قراءة monorepos حديثة.
ESLint و Prettier و CI
TypeScript وحده يفحص الأنواع، لكن مسار بناء محترف يضم:
- ESLint + @typescript-eslint: يكتشف أنماطاً خطرة لا يُنبه لها compiler (floating promises، unsafe any، وغيرها). أضفه بـ
npm install -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin. - Prettier: تنسيق كود موحد تلقائياً.
npm install -D prettierثمnpx prettier --write . - CI (مثال GitHub Actions):
- run: npm ci
- run: npx tsc --noEmit # typecheck
- run: npx eslint . # lint
- run: npm test # tests
البناء بدون هذه الطبقات يعطيك TypeScript بدون شبكة أمان. الأخطاء تصل للإنتاج بدلاً من أن تُصاد في pipeline.
قاعدة production
لا تنشر مشروع TypeScript مع أخطاء typecheck معروفة إلا بقرار واعٍ وموثق. الخطأ في النوع غالباً علامة على غموض حقيقي.