ecma402: the source repository behind the ECMAScript Intl specification

The repository is the spec, not an implementation

The README states the scope in one line. This repository contains the source for the current draft of ECMA-402, the ECMAScript Internationalization API Specification, and that source is processed to obtain a human-readable version published at tc39.es/ecma402. So there is no library here to depend on, and the package.json marks the package as private, which is consistent with that, since publishing it to a registry would be meaningless. What the repository does contain is the specification text and the machinery around it. The tree shows a spec/ directory with the document source, a biblio/ directory for the bibliography, docs/ for supporting material, img/ for the images the document uses, scripts/ for the build helpers, and a meetings/ directory that holds the task group meeting material. If you are trying to find out why an engine behaves a certain way with a locale, this is where the normative answer is written down.

Building the document is an npm script

The development section of the README is short and exact. After cloning you run npm install to set up the environment, then npm run build to build the spec or npm run watch to set up a continuous build, and the results appear in the out directory, which npm run clean deletes. The package.json shows what those scripts actually do, and the pipeline is built on ecmarkup with the ECMA-262 bibliography as a pinned dependency:

    "build-to": "ecmarkup --verbose --load-biblio @tc39/ecma262-biblio spec/index.html",

The full build adds linting in strict mode, and there is a separate script that writes the result to the null device so the document is linted without producing a file, which is the test command:

    "watch": "npm run build-only -- --lint-spec --watch"

The strict lint flags are the interesting part for a specification, because ecmarkup can check that the algorithm steps, the internal slots and the cross references in the text are consistent, and a broken cross reference is an editorial bug that would otherwise reach the published draft. There is also a build-for-pdf script that uses the old table of contents mode, since the PDF edition of the specification cannot use the same navigation as the HTML one.

Proposals are tracked in three stages, and elsewhere

The proposals section explains how the specification grows, and the important detail is that the work happens across repositories rather than inside this one. Proposals follow the TC39 process and are tracked in the proposals repository, with separate lists for finished proposals, active proposals and stage 0 proposals. The stage 0 list is the early ideas that have not yet been accepted for discussion, the active list is what the task group is currently working on, and the finished list is what has already been merged into the standard. The README also points at a wiki page for progress tracking that covers the status of tests, documentation and browser implementations of proposals, which is the resource you want when you are trying to find out whether a feature you have read about in a proposal is actually shipped in browsers, which is a different question from whether it is in the specification.

The task group is where the consensus happens

Contributing to ECMA-402 is described as being run by the ECMA-402 Task Group under TC39, and the mechanics are stated plainly. The task group achieves consensus and brings recommendations to TC39, it has a monthly teleconference, and community members who have followed the procedures in CONTRIBUTING.md are welcome to join that monthly meeting, with a calendar link for the schedule and how to dial in. You also have to apply for membership in the delegates mailing list, which is hosted on chromium.org. The two step process, follow the documented procedures and then apply for delegate membership, is the usual TC39 pattern and it explains the pace of the work. A specification that is reviewed by delegates rather than by a benevolent maintainer is slower to change and much harder to get wrong.

Candidates freeze the text, and the version number is the spec's own

The release history in this repository is unusual and worth understanding before you rely on it. The tags are not software releases in the usual sense, they are candidate snapshots of the standard, with es2021-candidate from March 2021, es2022-candidate from March 2022 and es2025-candidate-2025-04-01 from April 2025. Each of those freezes a particular text of the specification at a particular moment, which is what a candidate is. The package.json carries a version of 9.0.0, which is the specification's own edition numbering rather than a package release, and the private flag means it never reaches a registry. The last push was on 2026-10-12 and the project is not archived, so the draft on the main branch is a moving target while the tagged candidates are the stable points.

The licence is part of the published document

The licence is handled unusually for a TC39 repository, and the reason is worth understanding. The repository metadata classifies the licence as one GitHub cannot categorise, and the package.json points at a clause inside the published specification rather than at a standard open source file, with the value set to SEE LICENSE IN the copyright and software licence section of the spec. There is a LICENSE.md file in the tree as well, and the file the README links to for the copyright and software licence question is that clause of the rendered document. The practical consequence is that the terms apply to the specification text as published, and the ecma262-biblio package that the build depends on carries its own licensing separately. Anyone copying normative text into a product or a dataset should read that clause rather than assume a permissive licence, and that is not legal advice, it is a pointer to the right document.

Where to look for the answer you actually need

For most readers the interesting files are not in the spec/ directory at all. The proposals repository answers what is coming, the progress tracking wiki answers what is shipped, and the rendered document at tc39.es answers what the standard currently says. The meetings/ directory in this repository is the one that most people never think to open, and it holds the task group material, so it is where you find the reasoning behind a change rather than the change itself. The README also points to Contributing to ECMAScript in the repository root for the current process on contributing proposals to the standard, and a CODE_OF_CONDUCT.md sits alongside it. The practical workflow for a developer is to check the proposal status first, read the spec text if you need normative wording, and only then look at the meeting notes to understand why it says what it says.

Editorial conclusion

Adopt the ecma402 repository if you implement, test or document internationalization behaviour in JavaScript and need the exact wording of the standard rather than a blog post about it, or if you want to see how a TC39 proposal moves from stage 0 to finished. It is not a runtime library and there is nothing to depend on, since the package is marked private and never published. Verify first which edition your implementation targets, because the tagged candidates go from es2021 through es2022 to es2025 and each freezes a different text, and read the licence section referenced in the package, which points at the copyright and software licence clause of the published specification rather than a conventional open source licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tc39/ecma402 on GitHub