"ES2015" seem to be missing in SpecData.json

[ghost]

An entry for ES2015 seem to be missing in SpecData.json (or maybe has it been removed?):

It's being referenced for example here:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes?raw&section=Specifications

and seem to render fine in the main HTML for the MDN page, but it can't be reversed looked via SpecData.json.

[jwhitlock]

It renders because it is handled as an alias for ES6 in SpecName and spec2:

https://github.com/mdn/kumascript/blob/b7f97c51dd2d8dea4bdd0e9be9eb12327165fa67/macros/SpecName.ejs#L36

https://github.com/mdn/kumascript/blob/b7f97c51dd2d8dea4bdd0e9be9eb12327165fa67/macros/spec2.ejs#L22

[ghost]

OK, so there is really no difference between ES2015 and ES2016? Although I see there are referenced as 6. and 7. editions respectively when rendered with different links.

In any case, my main question is not so much about the rendering - that was more for reference; would it be possible to have it included in the SpecData.json file itself?

This would be very helpful for automated tasks which try to use the specification data and where SpecData,json, AFAIK, is the only resource that can be used for reverse lookups on MDN (?).

[jwhitlock]

I think a solution would be to add an option aliases member, with a list of aliases. So it would become:

{
  "ES6": {
    "name": "ECMAScript 2015 (6th Edition, ECMA-262)",
    "url": "https://www.ecma-international.org/ecma-262/6.0/",
    "status": "Standard",
    "aliases": ["ES2015"]
},

I'm not familiar with the standards process, so others will have to comment on ES2015 vs ES2016. ES2015 / ES6 is specifically addressed on https://developer.mozilla.org/en-US/docs/Web/JavaScript, as well as the yearly release cycle.

[ghost]

Thanks for the *ejs files btw. They are very helpful to make a workaround with manually duplicating those entries for the aliases, much as the script does.

I think a solution would be to add an option aliases member, with a list of aliases.

I think this could be workable, but I see a added problem in that you will actually have to iterate each key to look up the aliases to find if there is an alias entry, or pre-process the file to add aliases as primary entries beforehand.

Considering the relative small size of the SpecData.json, would it not be simpler and more practical to just "flatten" the file to include the alias entries? Of course, you will get duplicate data for some, but it seem to be basically, AFAICS, what the ejs files already are doing, but dynamically.

A flattened JSON file could be read as-is and an alias or primary name could be used directly as key without needing the extra step mentioned (externally at least). I'm not sure if that would be cumbersome to implement?

[jwhitlock]

I'm negative on adding duplicate entries. It makes it easier to parse but harder to maintain. When the W3C cleans house and moves specs around, it will be easy to make the error of changing one URL but not the other. An aliases attribute puts the burden on the users of the data, but makes it impossible to accidentally fork the data.

The long-term solution is to use a consistent identifier in the documentation (ES6 everywhere, replacing ES2015), and get rid of the aliases. This is manual and inefficient today, and some big changes are needed to make it easy to make global changes like that. The long-term solution is where I should focus, and leave today's JSON file to others, to pick duplicate data or more complex parsing (or leave it as it is).

[ExE-Boss]

Or prefer ES2015, which is what ECMA uses.