[FIX] Switch from esprima to espree

[codeworrior]

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 .

Thank you for your contribution! 🙌

To get it merged faster, kindly review the checklist below:

Pull Request Checklist

• Reviewed the Contributing Guidelines
  • Especially the How to Contribute section
• No merge commits
• Correct commit message style

[coveralls]

Coverage increased (+0.005%) to 94.726% when pulling 7f117d6 on switch-from-esprima-to-espree into b86f0fa on master.

[RandomByte]

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?

As discussed earlier today, we should always parse the latest ECMAScript version (just like browsers do). Projects should use linters to enforce specific versions.
We should always assume sourceType "script" for now. In the future we might detect modules based on file suffix or package.json configuration.

To make this part of a non-major UI5 Tooling release we would need to use espree v6 as all later versions require Node.js >10.

[codeworrior]

Going with espree ^6.0.0 however, we would miss at least the following syntax features:

• 75e80bc Update: support ?? operator, import.meta, and export * as ns
• 872645c Update: support optional chaining
• bd0a405 Update: support logical assignment and numeric separators

where the second one hurts most.

[RandomByte]

Still better than nothing, right? So maybe go with v6 for now and upgrade to v8 with UI5 Tooling 3.0?

[RandomByte]

Validated 7ea1a69 successfully in a smoke test run and locally by building the webc libraries 👍

[codeworrior]

Are you okay with the parseJS module? In the tests, I found it a bit strange that the module has the same name as one of its named exports. If someone has a better proposal, I would be glad to rename it.

• Module: parseUtil
• Exports: parseJS, Syntax

[RandomByte]

Yeah, parseUtil seems to be a better name for the module

[RandomByte]

I'll do the rename

[RandomByte]

Decided on parseUtils to align it with the already existing ASTUtils.

What about parseJs instead of parseJS 🤔 🙈

[codeworrior]

Reg. parseJs you do what you have to, but for me it looks wrong...

[RandomByte]

Well there is already JSTokenizer.parseJS, so let's rather stick with it here too.

Anything left here?

[codeworrior]

I think we're good to go...

[pubmikeb]

Going with espree ^6.0.0 however, we would miss at least the following syntax features:

• 75e80bc Update: support ?? operator, import.meta, and export * as ns
• 872645c Update: support optional chaining
• bd0a405 Update: support logical assignment and numeric separators

where the second one hurts most.

Meanwhile, there is already Espree 9.0 and Node.js 17.0, perhaps it is better to not stick with already outdated versions but go forward directly to the latest available versions, perhaps even towards late beta/RC versions. This will ensure the support of cutting edge features.

[RandomByte]

According to the package.json, Espree 9.0 still supports all active Node.js versions. So it shouldn't be a problem to upgrade directly to 9.0 with our next major.