The practical default for long-lived JavaScript
TypeScript succeeds because it changes how developers work without asking them to abandon JavaScript. Add annotations where they buy clarity, let the compiler infer the rest, and emit normal JavaScript for browsers, servers, workers, and other hosts. The editor can then follow symbols across files, complete properties, explain incompatible values, and rename APIs with far more confidence than plain text search.
That value grows with the size and lifetime of a codebase. A small script may not need an interface for three object properties. A product with several teams, shared packages, years of migrations, and thousands of call sites does. Types turn assumptions about request handlers, component props, configuration, and library contracts into information that both the compiler and the next maintainer can inspect. Declaration files extend much of that benefit to ordinary JavaScript dependencies.
Adoption can be incremental. TypeScript accepts JavaScript, provides JSDoc-based checking, and lets a project tighten settings over time. That makes it much less disruptive than moving an application to a different runtime or language. The Apache 2.0 license, npm distribution, editor support, and compatibility with the JavaScript ecosystem remove most organizational objections.
What the type system does and does not promise
TypeScript is designed to identify constructs likely to be errors, provide structure for large programs, and emit recognizable JavaScript without runtime overhead. It uses a structural, erasable type system. If two values have compatible shapes, they can often be used in the same places even when their authors never declared a relationship. That fits JavaScript's existing patterns and makes third-party libraries practical to describe.
The project explicitly does not aim for a sound or provably correct type system. Productivity and compatibility sometimes win over theoretical guarantees. A type assertion can overrule the checker, any can open a hole, declaration files can be wrong, and complex generic behavior can still surprise experts. Open issue #63749, for example, reports order-dependent access behavior for a protected field in an intersection under TypeScript 7.
Types also disappear before the program runs. A declared API response shape does not inspect the bytes received from a server. Environment variables remain strings or missing values regardless of their annotations. User input, database records, messages, and decoded JSON need runtime schemas or explicit validation at the boundary. TypeScript makes the code after validation safer; it is not the validation itself.
Easy installation, consequential configuration
The installation really is npm install -D typescript. The harder part is agreeing on the contract in tsconfig.json. Strict mode enables a family of stronger checks, and the official documentation warns that future versions may add stricter behavior beneath that umbrella. That is usually worth accepting, but upgrades can reveal new errors. Teams should pin the compiler, run it in CI, and upgrade deliberately rather than letting every developer use a different global version.
Module settings deserve equal attention. The chosen module format, resolution algorithm, runtime, package exports, bundler, test runner, and declaration output must describe the same world. Many apparently mysterious TypeScript errors are integration mismatches at these boundaries. A starter framework often supplies good defaults; a library publishing several module formats needs explicit compatibility tests.
The compiler is not an entire build system. TypeScript's design goals call an end-to-end pipeline a non-goal. It can check types and emit JavaScript, but production applications commonly use another tool for bundling, minification, CSS, assets, hot reload, and code splitting. SWC or another fast transformer may strip TypeScript syntax while tsc --noEmit handles checking. That split is sound when both use compatible syntax and configuration.
TypeScript 7 changes the implementation underneath
The project is in the middle of its largest engineering transition. The JavaScript compiler represented by this repository reached a GitHub release of 6.0.3 on April 16, 2026. The npm registry now reports TypeScript 7.0.2, built from the native Go port developed in microsoft/typescript-go. The staging repository says it will eventually merge back into microsoft/TypeScript.
For normal application code, the goal is familiar behavior with much faster tooling. The native-port status table marks parsing, type checking, JavaScript output, declaration output, watch mode, project references, and incremental builds as done. It still marks the language service as in progress and the public API as not ready. It also notes intentional changes from 6.0 and incomplete resolution modes.
That distinction matters. Most applications should test 7.0 in a branch and compare diagnostics, output, editor behavior, and build time. Tool authors using compiler nodes, custom language-service plugins, or APIs under typescript/lib need a deeper migration plan. Issue #63752 shows a current edge involving custom TypeScript-flavored file extensions and language-service size limits. Do not assume package-name continuity means internal API continuity.
Health is split across two repositories
The repository's last recorded push was August 14, 2026, and issues were updated August 15. Its 5,077 open items combine issues and pull requests, including years of suggestions as well as current bugs. The large number reflects the language's reach and a long-running design forum, not 5,077 confirmed defects.
The README now limits code changes here to security problems, serious recent regressions, and major crashes, while directing most fixes to the Go port. Feature and behavioral work is paused in this implementation. Meanwhile, the issue tracker includes a TypeScript 7.1 iteration plan and current native-compiler bugs. Read activity across both repositories before judging momentum.
TypeScript remains the best general choice for substantial JavaScript development. Start with strict mode, validate untrusted data at runtime, and keep the build chain understandable. Flow mainly makes sense for an existing Flow investment, ReScript for teams willing to choose a different source language, and SWC for transformation speed without integrated checking. The TypeScript 7 migration warrants testing, but it does not undo the language's overwhelming practical advantage.