JS to TypeScript

How to use JS to TypeScript

1. Paste your JavaScript.
2. Read the annotated output as a first draft.
3. Rename the file, run the compiler, and fix what it reports — that is the real conversion.
4. Inferred types are a starting point; the compiler, not a converter, does the real work.
5. Prefer unknown to any when you cannot determine a type — it forces narrowing rather than disabling checks.
6. Types are erased at compile time and provide no runtime validation.

Migrate incrementally, which TypeScript is designed for

You do not convert a codebase in one pass. Rename a file to .ts, let the compiler tell you what it cannot infer, fix those, and move on — with allowJs on so typed and untyped files coexist. Start at the leaves, with utilities and types that nothing depends on, and work toward the entry points; converting a module before its dependencies means writing types twice. The compiler is the migration tool, and a converter only saves you the mechanical first pass.

any is a hole in the type system, and it spreads

Annotating something as any turns off checking for it and everything derived from it, which makes the error go away and removes the value you converted for. unknown is the honest alternative: it accepts anything, like any, but forces you to narrow it before use, so the check happens where the data enters rather than nowhere. Turn on noImplicitAny early, before the codebase fills with silent anys that are painful to find later.

The compiler options that decide how much this is worth

strict is the one that matters, and it is worth turning on at the start of a migration rather than after, because retrofitting strictness to a large converted codebase is miserable. Its most valuable component is strictNullChecks, which separates a value from a value-or-null and catches the single most common class of runtime error in JavaScript. Without it, TypeScript will happily let you call a method on something that might be undefined.

Types vanish at runtime

TypeScript compiles to JavaScript by deleting the annotations. There is no runtime checking whatsoever, so a server that returns something other than what your interface promises produces an application that compiled cleanly and crashes anyway. Anything crossing a boundary — an API response, a form submission, parsed JSON, a message from another window — needs a runtime validator. Zod and Valibot let you define the schema once and derive the type from it, which keeps them from drifting apart.