This page documents the process and requirements for submitting feature requests (suggestions) to the TypeScript repository. It covers the GitHub issue template, the viability checklist, and how proposals are evaluated and accepted. For information about reporting bugs, see 15.5. For requesting changes to the standard library declaration files, see 15.7. For module resolution issues, see 15.8.
Note: New feature contributions targeting the compiler implementation should be directed to microsoft/typescript-go as development in the current JavaScript-based codebase is winding down. See CONTRIBUTING.md1-3 for the current policy.
Feature requests are filed as GitHub issues using the "Feature request" issue template. The process moves through the following stages:
Feature Request Lifecycle
Sources: .github/ISSUE_TEMPLATE/feature_request.yml1-74 CONTRIBUTING.md39-52 .github/ISSUE_TEMPLATE/config.yml1-16
The template instructs submitters to complete two steps before creating a new issue.
The TypeScript wiki FAQ contains a "Common Feature Requests" section that lists many popular suggestions that have already been considered. Issues that duplicate FAQ content are closed without elaboration.
TypeScript has over 2,000 open suggestions. The template explicitly notes this and recommends:
| Search method | Details |
|---|---|
| GitHub search | https://github.com/Microsoft/TypeScript/search?type=Issues |
| Search engine | site:github.com/microsoft/TypeScript <keywords> |
| Search scope | Include closed issues; a prior duplicate may have been closed |
| Synonyms | Check related constructs (e.g. interface vs type alias vs class) |
Sources: .github/ISSUE_TEMPLATE/feature_request.yml6-13 CONTRIBUTING.md13-22
The template is defined in .github/ISSUE_TEMPLATE/feature_request.yml and contains four structured sections.
Sources: .github/ISSUE_TEMPLATE/feature_request.yml15-73
| Field ID | Type | Required | Purpose |
|---|---|---|---|
search_terms | textarea | yes | Keywords searched before filing; aids future duplicate discovery |
viability_checklist | checkboxes | yes (all 6) | Hard criteria the suggestion must pass |
suggestion_summary | textarea | yes | Concise description of the proposed addition or change |
motivating_example | textarea | yes | Short developer-facing explanation, as if announcing in a blog post |
use_cases | textarea | yes | Problem being solved, shortcomings of current approaches, current workarounds |
Sources: .github/ISSUE_TEMPLATE/feature_request.yml15-73
This is the most important gating mechanism in the feature request process. All six criteria are marked required: true in the template, meaning a submitter cannot submit the form without checking all of them.
Sources: .github/ISSUE_TEMPLATE/feature_request.yml28-47
| Criterion | Rationale |
|---|---|
| No breaking change in TS/JS | TypeScript maintains strong backward compatibility guarantees |
| No runtime behavior change | TypeScript's type system is erased at runtime; it must not alter JS semantics |
| No type-dependent JS emit | The emitter cannot produce different JS output based solely on the types of expressions |
| Not a runtime feature | TypeScript is not a general-purpose language extension; new JS syntax is a TC39 concern |
| Not a new utility type | Utility types have a dedicated policy; see the "No New Utility Types" wiki page |
| Agrees with Design Goals | Proposals outside TypeScript's stated design goals will not be accepted |
The "type-dependent emit" criterion directly relates to the emitter's architecture — see 2.4 for how the emitter and type checker interact.
Sources: .github/ISSUE_TEMPLATE/feature_request.yml36-46 CONTRIBUTING.md121-123
The CONTRIBUTING.md file CONTRIBUTING.md43-51 lists what the team finds useful when reviewing proposals:
Acceptance is signalled by a team maintainer applying one of the following signals to the suggestion issue:
| Signal | Meaning |
|---|---|
Label: help wanted | Approved for contributor implementation |
Milestone: Backlog | Approved and queued for future work |
Features without one of these signals will not be accepted as PRs, even if the implementation is complete. The CONTRIBUTING.md explicitly states CONTRIBUTING.md121-123:
Features (things that add new or improved functionality to TypeScript) may be accepted, but will need to first be approved (labelled "help wanted" or in the "Backlog" milestone) by a TypeScript project maintainer in the suggestion issue.
Features that have language design impact or are adequately satisfied by external tools will not be accepted.
Declined suggestions are eventually closed automatically. The close-issues.yml workflow .github/workflows/close-issues.yml33-50 runs daily and closes issues with the following labels if they have seen no activity for 2 days:
| Label | Typical reason for closure |
|---|---|
Declined | Explicitly declined by the team |
Out of Scope | Outside TypeScript's design goals |
Too Complex | Implementation cost outweighs benefit |
Design Limitation | Constrained by fundamental design decisions |
Working as Intended | Behavior is correct as designed |
Sources: .github/workflows/close-issues.yml41-50 CONTRIBUTING.md119-123
Once a feature issue is approved (help wanted or Backlog), contributors may implement it. The PR template .github/pull_request_template.md5 requires that every PR has an associated issue in the Backlog milestone. For the full PR process, see 15.3.
If a feature changes the public compiler API (e.g. additions to typescript.d.ts), the pr-modified-files.yml workflow .github/workflows/pr-modified-files.yml124-138 automatically notifies senior maintainers and requests documentation of breaking changes on the API Breaking Changes wiki page.
Sources: .github/workflows/pr-modified-files.yml124-138 .github/pull_request_template.md1-21 CONTRIBUTING.md119-131
The issue template selector is configured in .github/ISSUE_TEMPLATE/config.yml Blank issues are disabled (blank_issues_enabled: false), ensuring all issues go through a structured template. General usage questions are redirected to Stack Overflow and the TypeScript Community Discord, keeping the issue tracker focused on bugs and actionable suggestions.
Refresh this wiki
This wiki was recently refreshed. Please wait 4 days to refresh again.