Add metadata about the ECMAScript edition that each feature was introduced in

[jedel1043]

It's pretty common for test runners such as test262.fyi to have a way to filter tests per ECMAScript edition, and some people like to analyze the conformance of engines per ES version.

Currently some runners have opted for using "features.txt" to extract this information, since features have a clear edition where they were introduced, and this could be used to know which minimum edition a test supports. However, there's some duplicate effort around this, since all runners have to maintain a separate mapping from the feature to the corresponding edition that introduced it:

• boa_tester
• test262.fyi

Seeing this, it would be nice to remove this duplicate effort by moving this metadata here.

Possible points of discussion

• [ ] Unified file (features list + metadata) vs two files (features file + metadata file).
• [ ] File representation
  • Keep using .txt
  • Transition to yaml/json/toml
  • Some other format?
• [ ] Edition representation
  • Numeric (ES6 -> 6, ES12 -> 12, ...)
  • String (ES6 -> "ES6", ES12 -> "ES12", ...)
  • Other
• [ ] Sentinel value for features that haven't been published
  • Big number (255/99/65535)
  • Negative number (-1)
  • Some string? ("N/A", "ESNext", "undefined", "None", ...)

[ljharb]

I think a unified file would be nicer, but that might interfere with how existing runners interface with the existing one.

(also, we should be using years, post-ES6, not edition numbers)

[jedel1043]

I think a unified file would be nicer, but that might interfere with how existing runners interface with the existing one.

This is possible to do using comments. The file already has some comments, so we could probably leverage that to add metadata in a backwards-compatible way.

[jedel1043]

(also, we should be using years, post-ES6, not edition numbers)

That's fair. I'm just using the edition identifier used by the two example runners, but it would also be understandable to use the more "official" identifier instead.

(runners could always subtract 2009 if they need the "semver" identifier)

[PawelJastrzebski]

Added concept of toml file in the PR.

[ljharb]

I'm not sure toml is a good choice solely because it's not natively parseable in node and other platforms (altho i love toml!)

[PawelJastrzebski]

That's a valid concern. Considering wider support, using a JSON file seems like a better choice, despite sacrificing some of the descriptive commentary.

added .json example to the PR

[jedel1043]

That's a valid concern. Considering wider support, using a JSON file seems like a better choice, despite sacrificing some of the descriptive commentary.

I think using YAML would be the most consistent in this case. Every test needs YAML in order to be interpreted correctly, so I think we should avoid introducing another metadata format.

[linusg]

Given you quoted test262.fyi as a use case I would strongly advise against YAML, browsers can't parse that :)

There are also languages that still don't have a decent YAML parser (for instance Zig), because YAML is an awfully complex format. I consider test262 using YAML metadata a mistake that's hard to rectify at this point, but please don't use that as an argument to add more YAML.

[jedel1043]

@linusg JSON is also fine by me. The one thing I would advocate for is to keep everything on the features.txt file by using the comments, instead of having two separate files.