Modern Bundlers & TypeScript: Transpile, Don't Check
Modern bundlers like Vite prioritize speed by only transpiling TypeScript files, not type-checking them. This enables sub-50ms updates during development. The footgun: your dev server won't report type errors; you must run tsc --noEmit separately.
Why it exists
Traditional build tools could be slow, as they often type-checked the entire application on every change. Modern bundlers like Vite were created to provide a near-instant feedback loop during development. To achieve this, they needed to decouple the slow, whole-graph operation (type-checking) from the fast, per-file operation (transpilation).
The mental model
Think of your bundler's dev server as a translator that only cares about grammar (syntax), not meaning (types). It rapidly converts TypeScript into JavaScript the browser can run, but it assumes you are checking the logic and type correctness separately. The two jobs, transpilation and type-checking, are fundamentally different, and mixing them slows everything down.
How it works
Vite uses a high-speed transpiler (like Oxc Transformer) to strip types from .ts files on demand. When you save a file, Vite only transforms that single file, making Hot Module Replacement (HMR) updates reflect in the browser in under 50ms. It does not build a knowledge graph of your entire project during development. Because of this, it cannot perform type-checking. For correctness, you rely on your IDE for real-time hints and run a separate command like tsc --noEmit --watch in your terminal to catch type errors across the project.
When to use it
This transpile-only approach is the default for modern front-end development with tools like Vite and frameworks like Vue or React. It's ideal for any project where a rapid, iterative development cycle is a priority. You get the benefits of TypeScript's developer ergonomics without paying the performance penalty on every save.
When not to use it
Do not rely solely on the dev server for code correctness. If your workflow requires that a type error must immediately break the build and be reported in the browser, you can use a plugin like vite-plugin-checker. However, this intentionally opts out of some of Vite's speed benefits by re-introducing a blocking static analysis step.
One canonical example
A developer changes a function's return type from string to number. The Vite dev server reflects the logic change instantly. If another component expected a string, the app might crash at runtime with a TypeError. Vite itself reports nothing. However, a separate tsc --noEmit process or the developer's IDE would immediately flag the type mismatch, preventing the error from being committed. The production build command is typically tsc --noEmit && vite build to guarantee type safety before shipping.
Interview question
What is a direct consequence of modern bundlers like Vite prioritizing transpilation over type-checking during development?
- a.The development server will immediately halt and display all detected type errors.
- b.The generated JavaScript will be less performant in the browser due to type removal.
- c.Type errors might not be reported by the dev server, potentially leading to runtime failures.Correct
- d.Hot Module Replacement (HMR) updates will be significantly slower due to the type stripping.
Why? this is the answer
The card states that modern bundlers only transpile, not type-check, during development to achieve speed, meaning 'your dev server won't report type errors' and an app 'might crash at runtime with a TypeError.' Therefore, type errors can go unnoticed by the dev server. The other options contradict the card's emphasis on fast HMR and the separation of concerns.
Just read this? Test yourself on what you have been reading.
Read the original → vite.dev
- #typescript
- #bundlers
- #vite
- #build-tools
- #web-performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles