The JavaScript specification is one HTML file, and its test command exits zero

The whole specification is one HTML file

The root of the repository contains a single HTML file that is the source of the current draft of the language specification. Everything else is machinery around it. A processing tool turns that source into the human-readable multipage edition published at the committee's site, and the readme makes the point that if you want to explore how the specification was written rather than what it says, you can read the same source with its full history in a code search tool. The dependency list explains the rest. There are two development dependencies: the specification authoring tool, and a DOM implementation used while processing. That is the entire toolchain for the normative text of a language that ships to billions of devices, and it is a useful corrective to the assumption that standards work involves a large system.

Four build targets, and one of them exists only to catch mistakes

The scripts fall into a clear pattern. One target builds the specification in one step by chaining to the multipage build with two extra flags, and those flags are the important part: one lints the specification document and the other enables strict mode, so a malformed construct fails the build rather than reaching the published edition. A second target does the multipage build itself, taking the source file and an output directory. A third sets up a continuous build that lints on every change, and a fourth deletes the output directory, which the pre-build hook recreates along with a copy of the image directory the document references. There is also a formatter for the source file and a snapshot build that runs the normal build and then inserts a warning banner, which is how a draft that is not yet ratified is marked. After a clone, the documented loop is install, then build or watch.

The official PDF is produced by a commercial typesetting engine

One script deserves reading on its own, because it tells you something about how the standard is distributed. Building the PDF runs a printable build first, which differs from the web build in three ways: assets are referenced externally into an output directory rather than inlined, and the document is built for print with the same lint and strict flags. Then a separate program from a different vendor is invoked with a script taken from the authoring tool's own installed files, and its output is the specification PDF. So the authoritative printable artefact of the language depends on a third-party typesetting engine being available in the build environment. Nothing about that is hidden, and nothing in the readme explains how that dependency is managed, which is worth knowing before you try to reproduce the PDF yourself.

The test script exits zero, on purpose

The manifest contains a script whose entire body is a successful exit. That is not an oversight and it is not laziness: the artefact here is a document, so there is nothing to assert in the usual sense, and correctness is enforced by the two flags the build passes. The document is linted, strict mode is on, and a snapshot build inserts a warning when the content is not a ratified edition. What the other scripts do is process and policy. One runs a script named for an intellectual property rights check against the tc39/ecma262 repository, which is how the committee's licensing rules are applied to contributions. Another runs a script that validates commits, so the history carries the metadata the process depends on. Both are the same idea as the lint flags: the checks that matter for a standard are editorial and procedural, not unit tests.

Proposals live in another repository, sorted by stage

Nothing about new language features happens in this repository. The readme points at the committee's process document and at a separate proposals repository, and then lists the states that repository tracks: finished proposals, active proposals, proposals at stage one, proposals at stage zero, and inactive proposals, each as its own list. New proposals follow the contributing document referenced from the readme. The separation matters for anyone trying to work out the state of a feature, because the specification you read here is the output of that process rather than the place the process happens. Two files at the root of this repository reflect the other side of it: one collects proposals that were withdrawn, and one covers the earliest stage, so the specification repository keeps the history even when the work moved elsewhere.

Generated Unicode tables are checked in, and an ignore list guards the metadata

Three HTML files at the root are tables of Unicode properties: binary properties, binary properties of strings, and non-binary properties. They are checked in as files rather than produced by any build script. Next to them is a JSON ignore list, esmeta-ignore.json. There is also a directory for the bibliography and one for the images the document embeds, and the build copies the image directory into the output, which is the only content the build copies by hand.

Publishing is a written process, and the licence lives inside the document

The repository carries the documents that make it a process rather than a file: a publishing document, a frequently asked questions file, a code of conduct, and the contributing guide. The licensing is the detail that stands out. The manifest's licence field does not name a licence at all. It points at the published specification itself, at the section covering copyright and the software licence, and a licence file also exists in the root. So for this project the terms are defined inside the normative text rather than alongside it, which is why the field reads the way it does and why anyone reusing the specification has to read that section rather than a licence header. The release naming is worth noticing too: a candidate edition in late March, the ratified edition in early July, and then an errata release weeks later whose name, ES2026, take two, marks it as the second attempt, which tells you the committee ships corrections as first-class artefacts.

Editorial conclusion

This repository fits anyone who needs the authoritative text of the language rather than a summary of it, and it fits proposal authors, since the process documents and the stage lists are linked from the readme. It does not fit as a source for reading, because the raw file is an authoring artefact and the built edition is the intended form. Before you rely on it, note what the build actually checks: a lint pass and strict mode on the document, not a test suite, since the test script exits zero by design. And if you need the PDF, understand that it is produced by a third-party typesetting engine, so that artefact depends on software outside this repository.

Frequently asked questions

Official sources

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