eslint should parse all stage 3 proposals

Per the discussion here;

Something being in stage 3 means, that barring some massive surprise performance issue discovered by browsers, that it almost certainly will ship. Browsers begin implementing in stage 3, since it’s a stage 4 requirement that 2 browsers support something first. What this policy means is that eslint will be unable to lint code that works in half of the browsers - that doesn’t seem ideal.

ES2016 was ratified in June, so it’s complete. However, the “yearly spec” is irrelevant - only what’s on Github matters, which is all the things that are stage 4 (which luckily doesn’t yet include any syntax changes).

In other words, I think that stage 3 - not just stage 4, and certainly not just when the yearly spec is ratified (which is not a meaningful milestone for implementations; stage 4 is when it’s final) - should be when eslint’s default parser adds support for any syntax changes.

Specifically: (proposal list)

• trailing commas in function signatures
• async functions / await keyword

[platinumazure]

Seems like this is something our TSC should discuss.

Worth noting that this is really about espree, the default parser for ESLint.

[alberto]

Thanks for your interest in improving eslint. Unfortunately, it looks like consensus couldn’t be reached on this issue and so I’m closing it. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach consensus after 21 days tend never to reach consensus, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.