تایپ‌اسکریپت در زمان اجرا وجود ندارد. خروجی کامپایلر جاوااسکریپتی است که تمام نوع‌ها از آن حذف شده‌اند، پس هیچ بررسی‌ای به مرورگر نمی‌رسد. هر چیزی که این زبان می‌گیرد، پیش از اجرا گرفته می‌شود یا اصلا گرفته نمی‌شود.
و اینکه چقدر می‌گیرد، یک تنظیم است. با پیکربندی پیش‌فرضِ سست، پارامتری که حاشیه‌نویسی ندارد بی‌صدا نوع «هرچیز» می‌گیرد و از آن به بعد هیچ خطایی روی آن گزارش نمی‌شود. کلیدی که این را عوض می‌کند در فایل تنظیمات است:
"strict": trueکه چند بررسی را با هم روشن می‌کند- مهم‌ترینشان
strictNullChecksاست - و
noImplicitAny، که پارامتر بدون حاشیه‌نویسی را به خطا تبدیل می‌کند
بدون بررسی تهی، null و undefined عضو هر نوعی هستند. یعنی چیزی که نوعش رشته است می‌تواند تهی باشد و کامپایلر چیزی نمی‌گوید، و همان خطای «خواندن صفت از مقدار تهی» که بیشترین سهم را در خرابی‌های فرانت‌اند دارد کاملا از دستش در می‌رود.
سه چیزی که از این زبان واقعا به کار می‌آید
نوع‌های اجتماعی، یعنی نوشتن اینکه یک مقدار یکی از چند حالت مشخص است، و کامپایلر مجبورتان می‌کند همه حالت‌ها را رسیدگی کنید. این بیشتر از هر ویژگی دیگری باگ می‌گیرد، چون بیشتر باگ‌های واقعی حالت فراموش‌شده‌اند و نه نوع اشتباه.
دوم، unknown به‌جای «هرچیز» برای داده‌ای که از بیرون می‌آید. اولی مجبورتان می‌کند پیش از استفاده بررسی کنید و دومی هیچ کاری نمی‌کند. سوم، استنتاج: بیشتر جاها لازم نیست نوع بنویسید و نوشتنش فقط تکرار است؛ جایی که باید نوشته شود مرزهاست، یعنی امضای تابع‌های عمومی و شکل داده‌ای که از یک رابط برنامه‌نویسی می‌آید.
نوع، قرارداد را ثابت نمی‌کند
این بزرگ‌ترین برداشت اشتباه از این زبان است. اگر بنویسید پاسخ سرور از نوع فلان است، هیچ چیزی این را در زمان اجرا بررسی نمی‌کند؛ فقط به کامپایلر گفته‌اید فرض کن این‌طور است. اگر سرور فیلدی را عوض کند، کد شما بدون هیچ خطای نوعی می‌شکند. برای مرز واقعی باید یک اعتبارسنج زمان اجرا بگذارید که هم داده را بررسی کند و هم نوع را بسازد، وگرنه همان تضمینی که فکر می‌کردید دارید وجود ندارد: قرارداد بین دو برنامه.
جایی که کار گیر می‌کند، پروژه‌ای است که از جاوااسکریپت آمده
الگوی رایج این است که یک تیم پروژه موجود را به تایپ‌اسکریپت می‌برد، با سخت‌گیری خاموش شروع می‌کند تا کد قدیمی کامپایل شود، و بعد هیچ‌وقت روشنش نمی‌کند. نتیجه بدترین حالت ممکن است: هزینه ابزار را می‌دهید و تقریبا هیچ باگی نمی‌گیرید. راهی که در عمل جواب می‌دهد این است که سخت‌گیری را از روز اول روشن کنید و فایل‌های قدیمی را یکی‌یکی وارد کنید، به‌جای اینکه همه را با هم وارد کنید و سخت‌گیری را خاموش. این تصمیم را هرچه دیرتر بگیرید گران‌تر می‌شود، چون کد بیشتری روی فرض‌های سست نوشته شده.
ابزار، و سالی که این حرف درست است
در سال ۲۰۲۶ کامپایلر رسمی tsc است، متن‌باز و رایگان، و همچنان تنها چیزی است که واقعا نوع‌ها را بررسی می‌کند. ابزارهای ساخت امروزی مثل Vite نوع‌ها را فقط حذف می‌کنند و بررسی نمی‌کنند، که سریع است و یعنی اجرای tsc --noEmit باید جدا و در خط لوله باشد؛ تیم‌هایی که این را نمی‌دانند فکر می‌کنند بررسی می‌شوند و نمی‌شوند. برای اعتبارسنجی مرز، zod بسته جاافتاده است و از همان طرح، نوع را هم می‌سازد.
پرسش بعدی این است که وقتی این نوع‌ها باید با یک سرویس بیرونی بخوانند، قرارداد کجا نوشته شود و کی می‌شکند، که نام‌گذاری، نسخه‌بندی، و خطایی که برمی‌گردانید است. و همان انتخاب میان بررسی زودهنگام و دیرهنگام، شکل عمومی‌اش در ترجمه پیش از اجرا، یا خواندن سطر به سطر در حین کار است.