Support Object Rest/Spread Properties (ES7+)

[thiamsantos]

Thanks for your project! But right now it breaks when rest/spread is used. Any workarounds?

[brentlintner]

Hey @thiamsantos. Thanks for opening an issue!

I tried a few examples, and think I figured out what exactly is the issue.

I am guessing you are using rest/spread with object literals / properties?

The example I used to reproduce:

https://gist.github.com/brentlintner/ef494397073c5e0768793c038cae450f

Possible solution:

It looks like this is a feature that was completed in Esprima for v5, as the spec went from Stage 2 to 3.

jquery/esprima#1588

So, I'll update to Esprima v5 as soon as I see the release? ;-D

[brentlintner]

Addendum: Esprima v5 is scheduled next year?! Ouch.

Perhaps I'll try using Acorn and Espree again like I was originally.

[thiamsantos]

Thanks for the feedback!

I am guessing you are using rest/spread with object literals / properties?

Yes, that's absolutely what I were doing. Sorry for the lack of information that I had provided.

Perhaps I'll try using Acorn and Espree again like I was originally.

What about babylon?

[brentlintner]

What about babylon?

Ooh. That could work really well (and it has types already for it). :-D Thanks for mentioning!

Yes, that's absolutely what I were doing. Sorry for the lack of information that I had provided.

No worries! Even an issue was appreciated. :-)

Given this, I'm going to update the title of this issue to ES7+ rest/spread as it technically falls outside of currently advertised support.

In the meantime, hopefully I can get a chance to play around with alternatives and ideally get ES7+ stuff supported before Esprima does in 2018! lol.

[brentlintner]

For reference: Object Rest/Spread Properties Proposal.

[ariya]

@brentlintner It probably does not hurt to have an explicitly stated policy (e.g. in README) regarding the support (or lack thereof) for non-standardized features (e.g. syntax proposals reaching various stages in TC-39 and not yet part of the official ECMA-262 spec).

Each choice has with its own advantages and drawbacks. Supporting every Stage 0-4 proposals increases the user base (e.g. everyone who is using bleeding-edge features with Babel), but it comes with an additional burden of always keeping track of the changes. The npm ecosystem is riddled with modules (and endless forks) which cause various levels of annoyance because they directly or indirectly rely on upstream libraries still stucked with an outdated syntax. If history is any indication, the situation will not get much better in the near future.

With Esprima, we elect to support only finalized and Stage-4 proposals. Hence, a major release happens only following a new ECMA-262 edition (annual basis), though there is an initiative to publish the development versions (jquery/esprima#1749).

Every project has its own trade-off!

[brentlintner]

Hey @ariya! Thanks for the comment, and especially for Esprima. It's been a pleasure using it in various projects. Kudos on the 4.0.0 release too (I plan to upgrade asap)! :-)

With Esprima, we elect to support only finalized and Stage-4 proposals.

Despite my surprise in my previous comments, that decision (given the rock solidness of Esprima) makes sense and I do support it, as much as it hurts for Stage-3 and under features not being supported (even with a flag). I do like the idea of development versions for Esprima, but IMO the plugin system that Babylon has (a la Acorn) lets you support stage-4/finalized and newer while using the prod ready version which is really powerful.

Each choice has with its own advantages and drawbacks.

I definitely agree, and I am hesitant to switch hastily before ensuring it does not compromise stable JS analysis.

FWIW I've been playing around today with babylon/babel-core/babel-generator etc to see if it could make it easier and it's been great to use as well and feels more or less as stable. What's really great is it can codegen jsx like escodegen-jsx but it is more actively maintained. Still, I've also ran into some odd and dispiriting tokenizer issues using Babylon that are hard to get around, whereas Esprima will tokenize more consistently I've found.

Given my messing around, my current thoughts are:

1. Support Esprima by default, mention support for Stage-3 and below in the project README (or similar, like you mentioned)
2. Optionally have babel support with a --babel flag or --esnext flag, and even possibly use presets the user has installed themselves, thereby keeping synt's prod deps lean

Note: I've pushed my current prototyping with Babel into a branch and created an issue for supporting stage-3 and below in general. I also plan to update the README about that when I upgrade Esprima to v4.x.

[brentlintner]

@thiamsantos closing this issue given the creation of #94. :-)

[brentlintner]

@thiamsantos it's been a long time lol, but fwiw the latest release should support everything up to ES15 now. 😄