Today we’re launching Test262 Report to provide JavaScript developers with up-to-date information on the state of new and existing language features across implementations. Test262 Report is based on daily runs of Test262, the ECMA-262 (“ECMAScript” or “JavaScript”) test suite, in nightly builds of JavaScript engines, and visualizes at-a-glance status of feature implementation progress.

Test262 Report Screenshot

Taking a look at our data, the good news for JavaScript developers is that the state of JavaScript is strong, with many of the language’s built-in Objects and syntax at 100% interoperability. JavaScript has many independent and complete implementations, numerous additional partial implementations, even more embeddings, and a broad-based design consensus process. This sets JavaScript apart as a programming language, and makes reporting like this key to legibility of new feature status.

Test262 is the JavaScript Ground Truth

Test262 is the official JavaScript language conformance test suite, containing comprehensive test material for each feature in the JavaScript language. New language features require these tests in order to be added to the ECMAScript® Language Specification, and implementers rely on these shared tests in order to implement new features correctly and confirm completeness prior to release. This makes Test262 results the ground truth for the state of a JavaScript feature.

In 2012 we started working directly on ECMA-262 and began accumulating internal ad-hoc knowledge of the state of JavaScript features. When we started working on Test262 in 2015, we found ourselves comprehensively using new language features prior to their implementation and release. Until today, we have not had a way to share this knowledge. Test262 Report is designed to capture the latent knowledge in our platform testing practice for our peers in the JavaScript development community.

How We Build Test262 Report

We are building test262.report daily from a run of all Test262 material (34,657 conformance test files at the time of this writing) in each of the 4 major engines, in default and strict modes, as well as in module code when ES Modules are present. We’ve built our testing bots using open source tools that we contribute to or maintain. We use Test262-harness as our runner and eshost to normalize host runtime environment disparities. We use jsvu to install the latest engine binaries.

Who is Test262 Report For?

We talked to a lot of JavaScript developers in the design stages of Test262 Report. JavaScript developer feedback led us to focus primarily on the interoperability tables you see on test262.report today. However, we also believe there are strong use cases for automation tools, implementers, specification authors and documentation maintainers.

We are working to make it possible for automation tools like Babel and TypeScript, can consume Test262 Report data to generate an environment baseline for code compilation based on realtime implementation status. We have gotten positive feedback from engine implementers and release managers about using other engine implementation statuses to prioritize their work and reality check the usability of a feature. Specification authors at TC39 (the Technical Committee that writes EcmaScript) are already using Test262 Report to quickly check the state of a feature prior to advancing it to Stage 4 (“Finished“) and including it in the specification. Lastly, we invite the broader community of folks thinking about the development of JavaScript to use these reports in blog posts and documentation about new and existing language features.

Roadmap for Test262 Report

Moving forward, we will continue to invest in infrastructure and CI maintenance for daily runs and reports. We would also like to add feature tags, search and more developer-friendly labels to the UI. Our priorities for the infrastructure are first to add results for additional JavaScript parsers and implementations like Babel, TypeScript, Flow, Preact, Moddable XS, JerryScript, and njs. We are also looking to add results for engine embeddings like Node.js, Firefox, Chromium, WebKit and Edge. Finally, in the medium term we would like to develop a data API and integrate with environment presets for compilers like Babel and TypeScript and compatibility tables like those on MDN.

In addition to Test262 Report, we would like to report on more areas of the Web Platform for developers. Our criteria are test completeness and veracity. We are already contributing to WPT (Web Platform Tests), and working with the Google Chrome ecosystem infrastructure team on the results collection behind wpt.fyi, so WPT is an obvious next candidate.

Conclusion

We are excited to launch, maintain and continue to improve Test262 report. We welcome your feedback, feature requests and bug reports on the public issue tracker for Test262 Report at github.com/bocoup/test262-report-issue-tracker. We will continue to improve the veracity and completeness of these reports, and are eager to collaborate with the community, our partners, and funders to make the Web Platform more predictable for developers.