TypeScript: why adopt it in modern projects

TypeScript is a language created by Microsoft that adds types to JavaScript. In practice, it warns you about certain errors while you write code, before anyone opens the site or runs the system.

This article explains what it does, what research measures about its benefits, why the topic has gained weight with AI coding assistants and how to adopt it in an existing project. The information was checked on October 8, 2026. Versions and adoption figures change quickly, so we give the date of each data point.

What TypeScript is

The official handbook sums up the idea in one sentence: TypeScript is JavaScript’s runtime with a compile-time type checker, according to the page TypeScript for the New Programmer.

Three concepts help make sense of that sentence.

A type is a description of what a value can be: a number, a string, a list of users, an object with specific fields.

Static checking is detecting errors without running the program. The checker reads the code and compares how each value is used with its expected type.

A superset means that all valid JavaScript code is also valid TypeScript syntax. TypeScript only adds rules about how values can be used.

One point often surprises people. According to the same handbook, after checking, the compiler erases the types and produces plain JavaScript. Types do not exist when the program runs and, as a principle, TypeScript never changes the behavior of JavaScript code.

What the check catches in practice

The handbook’s classic example is a typo in a property:

const box = { width: 10, height: 20 };
const area = box.width * box.heigth;
// Error: Property 'heigth' does not exist on type '{ width: number; height: number; }'

In plain JavaScript, this code runs and produces NaN (the special “not a number” value), with no warning. The defect only shows up when someone notices the strange result. With TypeScript, the editor underlines the error right away.

The same applies to other common situations: passing a string where a number was expected, forgetting a required field or trying to use a value that may be null (empty). The handbook even cites 4 / [], dividing a number by an array, which JavaScript accepts and TypeScript rejects.

There are also gains that do not show up as errors. With declared types, the editor knows what each function receives and returns. That improves autocomplete, go-to-definition and renaming across several files at once.

What research says about types and bugs

The question “do types reduce bugs?” is an old one, and the answers are less categorical than marketing suggests.

The most cited study on JavaScript is To Type or Not to Type, by Zheng Gao, Christian Bird and Earl T. Barr, presented at ICSE 2017. The authors took real bugs from public GitHub projects, went back to the code before the fix, added type annotations and tested whether TypeScript 2.0 or Flow (another checker, from Facebook) would flag an error.

The result: the two checkers detected, on average, 15% of the bugs analyzed.

The paper itself explains why this figure tends to underestimate the benefit. It only includes bugs that reached the public repository, that is, bugs that had already passed through testing and review. Errors caught during development, before the commit, are left out. Gains such as documentation and autocomplete are not counted either.

At the same time, the study does not prove that adopting TypeScript cuts 15% of the defects in any project. It measures what a checker would have flagged in a specific sample, under the assumption that developers would annotate the code completely.

Broader research calls for additional caution. A reanalysis published by Emery Berger and co-authors in 2019, On the Impact of Programming Languages on Code Quality, revisited a well-known study that associated languages with defects on GitHub. The conclusion was that only four languages kept a statistically significant association with defects, and with an “exceedingly small” effect, in the authors’ words.

In the editorial team’s reading, the body of evidence supports a moderate claim: static types catch a real, measurable share of errors, especially “fit” errors between parts of the code. They do not replace testing, review or good architecture.

Types and AI-generated code

The argument has recently gained strength with coding assistants. Language models generate code by predicting one piece of text at a time, and nothing in that process guarantees that the result compiles. To understand why models make confident mistakes, see AI hallucinations.

A paper by researchers from ETH Zurich and UC Berkeley, Type-Constrained Code Generation with Language Models (2025), measured this in TypeScript. In the evaluation of open models from 2 to 34 billion parameters, on average 94% of compilation errors came from type-check failures, and only 6% were syntax errors.

This has a practical consequence. In a typed project, a good share of the errors the model makes turn into a clear compiler message, which the agent itself can read and fix. Claude Code’s documentation, for example, lists among the agent’s tools the ability to see type errors after each edit, a feature that relies on language-specific plugins. We explain this loop in how Claude Code works.

GitHub uses the same reasoning to explain usage data. In its Octoverse 2025 report, published on October 28, 2025, the company links TypeScript’s growth to a preference for typed languages that make agent-written code more reliable. This is GitHub’s interpretation, not an experimental result.

How widely TypeScript is used

Two dated surveys give an idea of adoption.

According to Octoverse 2025, in August 2025 TypeScript overtook Python and JavaScript to become the language with the most monthly contributors on GitHub: 2,636,006, up 66.6% in one year. The report itself warns that other indexes, with other methodologies, may still put JavaScript or Python ahead. It also notes that the main UI frameworks, such as Next.js, Astro, SvelteKit and Angular, already scaffold projects in TypeScript by default.

In the 2025 Stack Overflow Developer Survey, 43.6% of all respondents said they had worked with TypeScript in the past year, versus 66% for JavaScript. Among professionals, the share rises to 48.8%. The survey was open from May 29 to June 23, 2025 and had 49,009 valid responses, according to its methodology. It is a sample of people who answer Stack Overflow, not a census.

The ecosystem in 2026: native compiler and Node.js

Two recent changes reduced TypeScript’s main friction point, the extra compilation step.

The first is the native compiler. In March 2025, Anders Hejlsberg, the language’s lead architect, announced a rewrite of the compiler in Go, aiming to be about ten times faster. TypeScript 7.0 shipped on July 8, 2026. According to Microsoft, full builds are typically 8 to 12 times faster. The same version turned strict mode on by default.

The announcement notes limits. Version 7.0 does not yet offer an application programming interface (API) for other tools, which is planned for 7.1. As a result, tools that embed TypeScript, such as those for Vue, Svelte, Astro and MDX, still depend on version 6.0 for editor support.

The second change is in Node.js, the environment that runs JavaScript outside the browser. According to the Node.js documentation, it runs .ts files directly by stripping the types, and this feature has been stable since versions 24.12 and 25.2. The important detail: Node only erases the types and performs no checking at all. Checking is still the job of the tsc compiler or the editor.

Costs and limits

Adopting TypeScript has costs, and it is worth knowing them beforehand.

• Learning curve. The handbook is blunt: you cannot learn TypeScript without learning JavaScript. Advanced types, such as generics, take time to master.
• Configuration. The tsconfig.json file marks the root of the project and sets the compiler options, according to the documentation. Poorly chosen options create friction with libraries and tools.
• False sense of security. Because types vanish at runtime, data coming from outside (forms, APIs, databases) is not checked automatically. TypeScript trusts what you declared. Validating these inputs at runtime is still necessary.
• The any escape hatch. The any type turns off checking for a value. Overused, it cancels the benefit without anyone noticing.

In very small or throwaway projects, the cost may outweigh the gain. In the editorial team’s assessment, the benefit grows with the size of the codebase, the number of people (or agents) working on it and the project’s lifespan.

How to adopt it without stopping the project

The official documentation describes a gradual path. You do not need to convert everything at once.

1. Check JavaScript files first. According to the page JS Projects Utilizing TypeScript, you just add the comment // @ts-check on the first line of a .js file. Types can be described in comments in JSDoc format, a standard for in-code documentation.
2. Let both coexist. The Migrating from JavaScript guide recommends the allowJs option, which makes the compiler accept .js and .ts files in the same project.
3. Convert one file at a time. The suggested first step is to rename a .js file to .ts and fix whatever comes up.
4. Tighten the rules gradually. The guide compares TypeScript’s strictness to a volume knob. First turn on noImplicitAny, which flags the places where the compiler would silently use any. Then strictNullChecks, which forces you to handle empty values.
5. Get to strict. The strict option turns on the family of stricter checks all at once. The documentation warns that future versions may add checks to this family, so an upgrade may reveal new errors.

If the project uses AI agents, include type checking (tsc --noEmit, which checks without emitting files) among the tests the agent runs before considering a task done and among the required checks before merging code into the main branch. We describe this workflow in Git and GitHub in AI projects.

What to take from this article

TypeScript does not change what your program does. It changes when you discover certain errors: in the editor, instead of in production.

The evidence points to a real but partial gain. Something like 15% of the public bugs studied in 2017 would be detectable by types, and in code generated by AI models most of the measured compilation errors are type errors. Testing, review and validation of external data remain indispensable.

If you are going to start, start small: // @ts-check in one file, then allowJs, then one .ts file, and only then strict mode. To see how this fits into an MVP built with agents, read how to build an MVP with AI agents.