# tc39/proposals: What the ECMAScript Proposal Tracker Actually Contains

> The tc39/proposals repository is the committee's index of JavaScript language proposals, not a library you install. It tracks stage 0 through stage 3 and finished proposals, with meeting notes and Test262 feature flags attached to each entry.

**tc39/proposals** — Tracking ECMAScript Proposals

- Repository: https://github.com/tc39/proposals
- Website: https://tc39.github.io/process-document/
- Stars: 19,194 · Forks: 749
- Language: Unknown
- License: not declared
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tc39-proposals

## What tc39/proposals is, and who reads it

This repository is the public index of ECMAScript proposals maintained by TC39, the committee that develops the JavaScript language. It is not a library, not a polyfill and not a build tool. The README links to four tracking files (stage-1-proposals.md, stage-0-proposals.md, finished-proposals.md and inactive-proposals.md) plus a separate ecma402/README.md for Internationalization API proposals. The main README then lists active proposals, which it defines as stage 2 and higher that have not been withdrawn, rejected or finished.

The audience is narrow and specific. Engine implementers use it to see what is coming. Tooling authors use it to decide whether a syntax feature is stable enough to parse. Library maintainers use it to judge whether a proposal is safe to target. If you write JavaScript and only want to know what you can ship today, this repository answers a different question than yours: it tells you what the committee is considering, not what your runtime supports.

## Stage numbers are the whole data model

The repository's organising principle is the TC39 process, which the README points to at the TC39 process document. Proposals are grouped by stage. Stage 3 entries appear in the active table, stage 2 proposals are included in the active list, and stage 0 and stage 1 proposals are pushed into their own files. Finished proposals move to finished-proposals.md. Withdrawn or rejected ones are not in the active list at all, and inactive-proposals.md collects the ones that stopped moving.

The README states plainly what stage 2 means: the committee expects these features to be developed and eventually included in the standard. That is a statement of intent, not a guarantee. A stage 3 proposal can still change before it reaches the standard, and the README's own table shows proposals that have been in the list for years, with meeting notes reaching back to 2016 for some entries. Reading the stage as a release date is the most common mistake this repository invites.

## Reading the active proposal table

Each row in the active table carries four useful columns: the proposal name, the author, the champion, and the Test262 feature flag, plus a list of meeting notes. The champion column matters more than it looks. A proposal with an active champion has someone responsible for pushing it through committee review; a proposal whose notes stop years ago is effectively parked, even if it still sits in the stage 3 table.

The Test262 feature flag is the most concrete artifact in the whole repository. It names the flag under which conformance tests for that proposal are gated in the Test262 suite. For example, the row for Legacy RegExp features lists legacy-regexp, and Source Phase Imports lists source-phase-imports. One entry, Dynamic Code Brand Checks, is marked No test262 tests, which tells you the test coverage is not wired up the same way. If you are evaluating whether an engine has implemented something, the flag is a better starting point than the stage number.

## Getting the repository and finding one proposal

There is no install step. The project is a collection of Markdown files, and the README gives no package, no CLI and no build command. You get it the way you get any repository: clone it, then read the files.

```bash
git clone https://github.com/tc39/proposals.git
cd proposals
ls
```

After the clone you should see the top-level entries the repository publishes: .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md, README.md, ecma402/, finished-proposals.md, inactive-proposals.md, stage-0-proposals.md and stage-1-proposals.md. The README's active table is where you look for stage 2 and stage 3 proposals, and each row links out to the proposal's own repository.

```bash
cat README.md
```

Reading README.md shows the active proposal table with its Proposal, Author, Champion, Test262 Feature Flag and Meeting Notes columns. From there you follow the proposal link out of this repository, which is where the actual specification text and design rationale live.

## The limits of an index repository

This repository cannot tell you whether a proposal is implemented in the runtime you target. It records committee status, not engine status, and the README never claims otherwise. There is no versioning, no release, and no changelog per proposal: the recent releases list is empty, and the last push to the repository was on 2026-09-15, which reflects edits to the tracking files rather than a software release.

The second limitation is that the repository is a pointer collection. A row gives you a name, an author, a champion, a flag and links to meeting notes. The reasoning, the syntax details and the open questions are in the linked proposal repository, and the README does not summarise them. If you need to know what a proposal actually does, this repository is the wrong tool by design; it is the map, not the territory. The third limitation is coverage: the README states that the active list contains only stage 2 proposals and higher, so anything earlier is deliberately kept out of the main table and moved to the stage 0 and stage 1 files.

## Where this fits against other JavaScript status sources

The common alternative is a compatibility table site, which tracks whether a given feature works in a given engine version. That answers a runtime question. tc39/proposals answers a process question: what the committee has accepted, what stage it is at, and who is pushing it. The two sources disagree often and neither is wrong, because a stage 3 proposal can be unimplemented for a long time and a shipped engine feature can exist behind a flag that no stage table records.

A second alternative is following the meeting notes directly. The repository links to those notes per proposal, which is genuinely useful, but reading raw notes across many meetings is far more work than scanning a stage table. The repository's value is that it compresses committee activity into a status column, at the cost of losing the argument behind each status change. If you need the argument, the notes are one click away; if you need the status, the table is faster.

## Maintenance, licensing and what to verify

The repository is not archived, and the last push was on 2026-09-15, so the tracking files are being edited. That does not make any individual proposal current: a proposal can sit in the stage 3 table with meeting notes that stop years earlier, which is exactly what the Legacy RegExp entry shows with notes reaching back to 2016. Treat the last push date as evidence that the index is maintained, not that the proposals in it are advancing.

The licence is not stated in the repository's README, so anyone planning to reuse the table contents in their own tooling should check the repository for a licence file before doing so. This is a factual gap, not a legal opinion, and it is worth resolving before you copy rows into a product. The same applies to the linked proposal repositories: each has its own terms, and this index does not speak for them.

## Conclusion

Use tc39/proposals if you need to know which JavaScript features are real, which are still moving, and which have stalled; the stage tables and meeting notes are the primary evidence. Do not expect a runtime, a polyfill or a changelog per proposal: the repository is an index, and each proposal lives in its own repository. Before you plan work around a feature, open the proposal's own README and check its Test262 feature flag rather than trusting the stage number alone.

## FAQ

### What is tc39/proposals?

It is the TC39 repository that tracks ECMAScript proposals, listing active stage 2 and higher proposals in the README and moving stage 0, stage 1, finished and inactive proposals into separate files.

### Does tc39/proposals include stage 1 and stage 0 proposals?

Yes, but not in the main active table. The README links to stage-1-proposals.md and stage-0-proposals.md, and states that the active list contains only stage 2 proposals and higher.

### How do I install tc39/proposals?

You do not install it. It is a set of Markdown tracking files with no package, CLI or build step, so the usual approach is to clone the repository and read the files.

### What does the Test262 feature flag column mean?

It names the flag under which that proposal's conformance tests are gated in the Test262 suite, for example legacy-regexp or source-phase-imports. One entry, Dynamic Code Brand Checks, is marked as having no Test262 tests.

### Does tc39/proposals tell me whether a feature is supported in my runtime?

No. It records committee stage and meeting activity, not engine implementation status, so a stage 3 proposal may still be unimplemented in the runtime you target.

## Sources

- [Issues](https://github.com/tc39/proposals/issues)
- [Project website](https://tc39.github.io/process-document/)
- [README](https://github.com/tc39/proposals/blob/main/README.md)
- [tc39/proposals on GitHub](https://github.com/tc39/proposals)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tc39-proposals