Object spread

[eddiemoore]

Seems that object spread doesn't work when converting.

// Doesn't work
return fetch(url, {
    ...opts,
    headers,
})

// Works
return fetch(url, Object.assign({}, opts, {
    headers,
}))

/XXX/node_modules/flow-jsdoc/app.js:84
                    throw err;
                    ^
Error: Line 33: Unexpected token ...
    at ErrorHandler.constructError (/XXX/node_modules/esprima/dist/esprima.js:3386:22)
    at ErrorHandler.createError (/XXX/node_modules/esprima/dist/esprima.js:3404:27)
    at JSXParser.Parser.unexpectedTokenError (/XXX/node_modules/esprima/dist/esprima.js:541:39)
    at JSXParser.Parser.throwUnexpectedToken (/XXX/node_modules/esprima/dist/esprima.js:551:21)
    at JSXParser.Parser.parseObjectPropertyKey (/XXX/node_modules/esprima/dist/esprima.js:1034:27)
    at JSXParser.Parser.parseObjectProperty (/XXX/node_modules/esprima/dist/esprima.js:1074:25)
    at JSXParser.Parser.parseObjectInitializer (/XXX/node_modules/esprima/dist/esprima.js:1140:35)
    at JSXParser.Parser.inheritCoverGrammar (/XXX/node_modules/esprima/dist/esprima.js:832:37)
    at JSXParser.Parser.parsePrimaryExpression (/XXX/node_modules/esprima/dist/esprima.js:904:38)
    at JSXParser.parsePrimaryExpression (/XXX/node_modules/esprima/dist/esprima.js:5355:97)
error Command failed with exit code 1.

[kegsay]

I'm leaning heavily on Esprima to parse JS files, so I'd need to check upstream to see if they handle that yet.

[wardpeet]

Don't think esprima has support yet (https://astexplorer.net/) but haven't checked beside that site. Babel parser does

[kegsay]

@wardpeet Great site, didn't know that existed! 😄 Yeah it looks like object spread isn't supported yet 😢

[wardpeet]

@Kegsay would you be open to move to the babel parser?

[kegsay]

Provided the tests still pass, sure!

[ariya]

For object rest/spread support in Esprima, please track https://github.com/jquery/esprima/issues/1588.

[kegsay]

That sounds great, I'll update the deps and give it a go. Thanks!

[ariya]

@Kegsay Note that there is no released version with that feature yet. You may want to keep an eye on https://github.com/jquery/esprima/issues/1749.

In general, I believe it is worth stating the project-specific policy regarding syntax (or any features, for that matter) that is not part of the official ECMA-262 specification (object rest/spread will be in ES2018, which is a year away). Things will change until the final specification, and that can create unnecessary churns.

[kegsay]

@ariya I sympathise with not wanting to chase a moving target: I would most likely do the same thing if I were in your shoes.

That being said, in order for this project to be useful in the real world, I need it to support all the weird and wonderful things JS devs are doing, and that so happens to be draft/experimental syntax (or rather, it's anything which the Babel devs want to implement since they are the ones who are effectively allowing devs to use this syntax).

As for the idea of using a separate "development" branch which tracks these things: I think it's a good idea overall. From a code hygiene perspective though, I think this ship has sailed given JSX support is gated behind a jsx flag, which presumably has exactly the same churn problem as new ECMA versions. You could do something similar for draft specs and gate them behind flags, although it might make the internals of Esprima messy with lots of conditionals. All in all though I don't really care which particular hoop I need to jump through to get Esprima to parse things, be it gates or different git repos, provided there is a way. Thank you for all your work on Esprima! :1st_place_medal:

[wardpeet]

#15 might give more options for developers to change parsers but it's not perfect yet.