Feature documentation is incomplete - only shows subset of capabilities, not all test262 results

[anivar]

Current Documentation Problem

Rhino's feature documentation is incomplete and outdated. It only covers a small subset of ECMAScript features, while test262.properties shows we test and support hundreds of features across multiple categories.

The Real Scope

Our test262.properties file (7,500+ lines) tests:

• Built-in Objects: Array, String, Object, Map, Set, Promise, etc. with all their methods
• Language Features: async/await, arrow functions, destructuring, generators, etc.
• Annex B Features: Legacy browser compatibility features
• Internationalization: Intl.DateTimeFormat, Intl.NumberFormat, etc.
• RegExp Features: All regex capabilities and flags

Currently, none of this comprehensive testing is reflected in our documentation.

Examples from test262.properties

built-ins/Array 2816/3077 (91.52%)
built-ins/String 1154/1212 (95.21%)
built-ins/Object 3289/3410 (96.45%)
built-ins/Promise 256/639 (40.06%)
language/expressions/arrow-function 192/343 (55.98%)
annexB/built-ins 58/241 (24.07%)
intl402/DateTimeFormat 234/456 (51.32%)

Impact

Developers cannot see:

• Which specific Array methods work (map, filter, reduce, etc.)
• Which String methods are supported
• Detailed language feature support
• Internationalization capabilities
• Legacy compatibility status

Proposed Solution

Create an automated system that:

1. Parses ALL entries from test262.properties
2. Automatically categorizes features by type
3. Generates comprehensive documentation showing every tested feature
4. Updates automatically when test results change

This would provide complete transparency about Rhino's capabilities, not just selected ES features.

[p-bakker]

Instead of building a new system, it would be a lot better to make the Kangax Compat table project more generic/extendible, after which we could get rid of the current outdated forked version of our own compat table docs and just create and host the latest compat table with our own data

I've proposed modifying the Kangax Compat table accordingly and the team behind it is open to it. I just don't have the time to bring it to frutition I'm afraid

The (now outdated) PR I created for this is: compat-table/compat-table#1881

I think resurrecting that is a more viable and future-proof approach then adding some new documentation mechanism

[anivar]

Thanks @p-bakker for the suggestion! Both approaches can definitely coexist and serve different purposes:

Kangax compat-table:

• Manual curation of specific ECMAScript features
• Cross-engine comparison (V8, SpiderMonkey, Rhino, etc.)
• High-level feature support overview
• Great for developers choosing between engines

This test262-based system:

• Automated from actual test results
• Comprehensive coverage of ALL test262 suites (3,025 features)
• Exact pass rates, not binary yes/no
• Includes non-ES features (annexB, intl402, harness tests)
• Updates automatically with every code change
• Single-engine deep dive into Rhino's capabilities

They complement each other well - compat-table for cross-engine comparison, this system for Rhino's detailed test-driven documentation.

PR #2089 implements the automated approach as a proof of concept.

[p-bakker]

The adjustments I proposed to the compat table project would allow for Rhino to host it's own version of the compat table, just comparing the different Rhino versions with each other

It also allows being generated from test results, namely the test results for running the tests contained in the compat table project, which are way more focused on whether an EcmaScript feature is supported for regular use-cases, which given a way better representation than the results of test262, which also covers a ton of edge cases or have failures to being dependant on other ES features

And the compat table does has tests on annexb or intl402

From my perspective an up to date compat table implementation (that can be automatically updated with each merge) would solve the 'problem' you set out to solve (which feature/method is supported for common/practical use-cases)

[p-bakker]

On top of that: our documentation doesn't live in the main Rhino repo anymore, but in https://github.com/rhino/rhino.github.io