Object spread

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]

@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! 🥇

[wardpeet]

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