After updating to 6.x all JS files return JS_SYNTAX_ERROR on web-ext lint

[cadeyrn]

Is this a feature request or a bug?

Bug. Similar to #1976.

What is the current behavior?

After running web-ext lint the validation doesn't work. Instead I get the following message for every JS file:

JS_SYNTAX_ERROR
JavaScript syntax error (Parsing as script error: Invalid ecmaVersion. at line: undefined and column: undefined)
There is a JavaScript syntax error in your code, which might be related to some experimental JavaScript features that aren't an official part of the language specification and therefore not supported yet. The validation cannot continue on this file.

What is the expected or desired behavior?

A Successful validation.

This happens every time with web-ext 6.0.0 and with web-ext 6.1.0 but not with web-ext 5.1.0 and not with web-ext 5.5.0. I tried to validate https://github.com/cadeyrn/newtaboverride.

Version information (for bug reports)

• Firefox version: Firefox 90a1
• Your OS and version: macOS 11.3.1
• Paste the output of these commands:

node --version && npm --version && web-ext --version

v15.6.0
7.4.0

[rpl]

@cadeyrn I need to dig a bit more to identify the "why" part, but it looks that the gulp-eslint dev dependency in the newtaboverride package is confusing npm dependencies resolution somehow.

Because of that, web-ext lint ([1]) ends up using espree v6 instead of espree v7.
espree v6 doesn't support the ECMA_VERSION value set to 12 (which is the value related to ECMAScript 2021) and throws that error.

To double-check that it is really the gulp-eslint dev dependency to be triggering that, I tried to temporarily remove gulp-eslint ([2]) and the unexpected parsing errors were not triggered anymore.

For your extension, it may be reasonable to migrate away from gulp-eslint (especially given that it seems it hasn't been updated for quite some time, last version released is from 2019), it seems that there is a gulp-eslint7 package that is more updated and may be a simple drop-in replacement (but I haven't checked if the package is well maintained and can be trusted, and so that is something for you to double-check before choosing it for your project).

Even if a workaround exist for your particular case, I'm not closing this issue yet and I'll try to come back to investigate it a bit more.

This issue looks pretty annoying and I'm pretty sure that there would be other combinations of dev dependencies that may also lead to this unexpected dependency resolution issue and then trigger these unexpected parsing error (which are going to be quite confusing, also hard to investigate given that the error doesn't provide any stack trace to help detecting where they are being triggered from).

---

[1]: well, actually the eslint instance that the addons-linter dependency does call to parse and validate the js file, which is what happens internally when web-ext lint is being executed
[2]: and also rebuilt node_modules/ directory, by removing it and running npm install instead of npm ci to rebuild it from package.json instead of the lock file

[vitonsky]

This bug is still actual. Check my pipeline log: https://github.com/translate-tools/linguist/runs/4347669128?check_suite_focus=true

I update packages and got this error. Builds run fine in browser.

Please, fix it. At this time i forced to disable testing step with this tool: translate-tools/linguist@b4447f2

[AprilSylph]

@vitonsky this is more recently a bug with npm caused by using eslint 7 and web-ext 6.6.0/addons-linter 4 in a project. See AprilSylph/Palettes-for-Tumblr#80 (comment) for the full details, it's very interesting.

As I understand it, the current solutions are:

1. Upgrading to eslint 8
2. Continuing to use web-ext 6.5.0
3. Using npm install --legacy-bundling
4. Using yarn

[rpl]

This issue has been fixed on the addons-linter side (mozilla/addons-linter#4078) and that fix has been introduced in web-ext by #2374.

This should now be fixed in the web-ext v6.7.0 release.