"Unexpected token" error - Drop Esprima dependency? #354
Comments
|
Thanks for reporting. Yes, with the recent terser upgrade, Esprima (used in our preload generation) is currently the only piece that is still lacking ES6 support. A switch to Espree seems reasonable. We'll discuss this in the team. I would be surprised if @codeworrior hasn't already looked into the differences between Esprima and Espree and the possible issues these could cause in our current implementation 😉 |
|
We discussed this in a small round and think switching to Espree makes sense. However our bundler also needs to understand the new ES6 language features, which needs some more effort. Related issues:
We added this topic to our internal backlog and keep you posted here. |
|
We should also consider to align with other parsers that we implicitly use. E.g. JSDoc now internally uses Babylon. |
Terser does its own parsing, but supports input as SpiderMonkey AST. |
|
As far as I remember, the path via SpiderMonkey AST didn't work for all ES6ff features. That was the reason why we finally had to serialize modified ASTs again before handing them over as a string to Uglify. Whether Terser has improved here and the SpiderMonkey AST is fully functional again, I can't say. During the work on PR SAP/ui5-builder#282, it was discussed whether we could switch to the Terser API, which unfortunately has a different representation of nodes. But I would prefer to stay with the SpiderMonkey AST format as it is more common. |
RandomByte
added
enhancement
|
Very much looking forward to use optional chaining with future versions of the ui5-tooling. 🚀 |
|
any update on this, how to resolve this issue. |
|
Im facing the same issues, are there any news to this problem? |
This is work in progress and can't be submitted as the used espree version (8.0.0-beta) is not a release version and it requires a newer NodeJS min version than the tooling. espree 8.0.0-beta was chosen as it switches the default for the ecmaVersion option from 5 (7.3.1) to latest. Before submitting, it also should be decided whether all parsing code should be routed through some helper utility, to simplify future updates / changes of the parser. At the same time, we should decide about the use of the sourceType and the ecmaVersion options. Should we expose them in ui5.yaml? Or should we rather leave that to the linting step? Fixes SAP/ui5-tooling#354 .
This is work in progress and can't be submitted as the used espree version (8.0.0-beta) is not a release version and it requires a newer NodeJS min version than the tooling. espree 8.0.0-beta was chosen as it switches the default for the ecmaVersion option from 5 (7.3.1) to latest. Before submitting, it also should be decided whether all parsing code should be routed through some helper utility, to simplify future updates / changes of the parser. At the same time, we should decide about the use of the sourceType and the ecmaVersion options. Should we expose them in ui5.yaml? Or should we rather leave that to the linting step? Fixes SAP/ui5-tooling#354 .
|
Until there is a solution for this issue you can apply the workaround that @lemaiwo pointed me to: Use ui5-task-transpile. You can find a sample configuration at ui5-deploy.yaml. |
A new module lib/lbt/utils/parseJS is introduced that exposes a parseJS function and a Syntax object with all AST node types. The new module is used in all places where JavaSCript code is parsed (incl. tests). The module uses espree v6 for parsing instead of esprima. This is the maximum version that can be used without introducing breaking changes to the tooling (higher versions of espree require higher node versions than documented in our package.json). The set of allowed parser options is limited to ease a later migration to another parser. Fixes SAP/ui5-tooling#354 .
A new module lib/lbt/utils/parseUtils is introduced that exposes a parseJS function and a Syntax object with all AST node types. The new module is used in all places where JavaScript code is parsed (incl. tests). The module uses espree v6 for parsing instead of esprima. This is the maximum version that can be used without introducing breaking changes to the tooling (higher versions of espree require higher node versions than documented in our package.json). The set of allowed parser options is limited to ease a later migration to another parser. Fixes SAP/ui5-tooling#354 Co-authored-by: Merlin Beutlberger <[email protected]>
|
Reopening until a new release has been done. Probably tomorrow afternoon |
|
We have switched parsers to Espree v6. We can't use any newer versions, because they require a higher version of Node.js than what UI5 Tooling currently supports. This means some ES6 features are still not supported:
We will probably add support for those by upgrading Espree with the UI5 Tooling 3.0 release. However, the "Unexpected token" error for spread operators reported in this issue is now resolved with UI5 CLI v2.11.2 🎉 |
Technically this is an Esprima bug, but I do report this here because Esprima seems to be outdated in general and does not support modern JavaScript.
I've heard about the Fork Espree, but thats just a suggestion.
Expected Behavior
ui5 buildshould compile modern JavaScript code.Current Behavior
The build fails if it encounters a spread operator.
Steps to reproduce the issue
ui5 buildContext
ui5 --versionwhen using the CLI):2.4.2v12.10.06.13.4Windows and WebIDEAffected components (if known)
Log Output / Stack Trace
The text was updated successfully, but these errors were encountered: