This page explains how to propose new features for the TypeScript language and compiler. It covers the viability requirements, submission process, and evaluation workflow that feature requests go through.
For reporting bugs in existing TypeScript functionality, see Bug Reports. For issues with standard library definitions, see Library Definition Issues. For questions about TypeScript usage, use Stack Overflow or the TypeScript Community Discord rather than filing an issue.
Important: The microsoft/TypeScript repository is currently in maintenance mode. TypeScript 6.0 is the last JavaScript-based release. Future TypeScript development, including new features and behavioral changes, is currently on pause until the Go-based rewrite (TypeScript 7.0) is completed at microsoft/typescript-go.
Currently, only critical fixes (crashes, security issues, or serious regressions) are being accepted for this repository. Feature additions are generally deferred to the new repository.
Sources: README.md31-39 CONTRIBUTING.md5-6 AGENTS.md1-7
Feature requests are suggestions for new or improved functionality in TypeScript. The TypeScript team maintains over 2,000 open feature suggestions, and proposals undergo careful evaluation against TypeScript's design goals and constraints. Not all feature requests are accepted, and many common ideas already have existing proposals in progress.
All feature requests must satisfy six mandatory criteria defined in the GitHub issue template. Suggestions that fail to meet these requirements are very unlikely to be accepted, regardless of their technical merit.
Sources: .github/ISSUE_TEMPLATE/feature_request.yml29-48
The feature must not break existing TypeScript or JavaScript code. TypeScript maintains strong backward compatibility, and changes that would cause previously working code to fail compilation or change behavior are not acceptable. .github/ISSUE_TEMPLATE/feature_request.yml37-38
The feature cannot alter the runtime behavior of existing JavaScript code. TypeScript aims to be a superset of JavaScript, and any valid JavaScript program must continue to execute identically when processed through TypeScript. .github/ISSUE_TEMPLATE/feature_request.yml39-40
The feature must be implementable without emitting different JavaScript code based on the types of expressions. TypeScript's type system is designed to erase completely at compile time, and features that would require type information at runtime violate this principle. .github/ISSUE_TEMPLATE/feature_request.yml41-42
TypeScript does not add new runtime functionality beyond what JavaScript provides. Features that require new library functionality, non-ECMAScript syntax with JavaScript output, or syntax sugar for JavaScript features should be proposed to TC39 instead. .github/ISSUE_TEMPLATE/feature_request.yml43-44
TypeScript does not accept proposals for new utility types. The built-in utility types like Partial<T>, Pick<T, K>, and Omit<T, K> represent common transformations, but the team has determined that adding more utility types does not scale well and such transformations can be defined in userland. .github/ISSUE_TEMPLATE/feature_request.yml45-46
The feature must agree with TypeScript's design goals. These goals include being a statically typed superset of JavaScript, preserving runtime behavior, matching ECMAScript evolution, and maintaining type system soundness where practical. .github/ISSUE_TEMPLATE/feature_request.yml47-48
The feature request workflow begins with thorough research and continues through template completion and community discussion.
Sources: .github/ISSUE_TEMPLATE/feature_request.yml1-73 CONTRIBUTING.md65-77
Before creating a new feature request, search thoroughly using:
site:github.com/microsoft/TypeScript <your keywords>Sources: .github/ISSUE_TEMPLATE/feature_request.yml7-11 CONTRIBUTING.md39-49
The feature request template requires four sections:
| Section | Purpose | Requirements |
|---|---|---|
| Search Terms | Help future users find the proposal | List keywords used during duplicate search .github/ISSUE_TEMPLATE/feature_request.yml17-25 |
| Suggestion | Summarize the proposed feature | Brief description of what would be added/changed .github/ISSUE_TEMPLATE/feature_request.yml52-53 |
| Motivating Example | Show why the feature improves TypeScript | Short blog-post-style explanation targeting developers .github/ISSUE_TEMPLATE/feature_request.yml59-61 |
| Use Cases | Explain real-world applications | What you want to use it for, shortcomings of current approaches, and workarounds .github/ISSUE_TEMPLATE/feature_request.yml67-71 |
Sources: .github/ISSUE_TEMPLATE/feature_request.yml14-73
Include code examples showing:
Sources: CONTRIBUTING.md70-77
Feature requests are one of several issue template types in the TypeScript repository:
| Template | Purpose | File |
|---|---|---|
| Bug Report | Report incorrect TypeScript behavior | bug_report.yml |
| Feature Request | Suggest new TypeScript functionality | feature_request.yml |
| Library Change | Fix/improve built-in type definitions | lib_change.yml |
| Module Resolution | Report module resolution problems | module_resolution.yml |
| Other | Issues not captured by other templates | other.yml |
Sources: .github/ISSUE_TEMPLATE/feature_request.yml .github/ISSUE_TEMPLATE/bug_report.yml .github/ISSUE_TEMPLATE/lib_change.yml .github/ISSUE_TEMPLATE/module_resolution.yml .github/ISSUE_TEMPLATE/other.yml
Approved feature requests may be labeled Help Wanted. However, given the current maintenance mode, contributors should note that development in this codebase is winding down. All new language features should be directed toward the typescript-go repository.
Sources: CONTRIBUTING.md5-6 README.md38-39
Additional resources for feature request authors:
Sources: .github/ISSUE_TEMPLATE/feature_request.yml11-47 CONTRIBUTING.md50-54 README.md41-47
Refresh this wiki