Linter objects to use of import.meta while extension works just fine

[pieterdd]

Describe the problem and steps to reproduce it:

1. Start from this minimal reproduction case: https://github.com/pieterdd/webextlinterissue
2. rm -rf dist && yarn build && yarn web-ext lint -s build

The following error appears:

Validation Summary:

errors          1              
notices         0              
warnings        0              

ERRORS:

Code              Message                       Description                                                  File                Line   Column
JS_SYNTAX_ERROR   JavaScript syntax error       There is a JavaScript syntax error in your code, which       popup.8fd6e017.js   1      1021  
                  (Parsing as script error:     might be related to some experimental JavaScript features                                     
                  Cannot use 'import.meta'      that aren't an official part of the language specification                                    
                  outside a module at line: 1   and therefore not supported yet. The validation cannot                                        
                  and column: 1021)             continue on this file.                                                                        
error Command failed with exit code 1.

The extension itself seems to work fine, but the linter still objects to it.

What happened?

I got a lint error.

What did you expect to happen?

Given that the extension seems to work fine, I expected not to get a lint error.

Anything else we should know?

Since I use Parcel as my bundler, I brought it up with the Parcel team before coming here. A member concluded:

This seems more like an issue with web-ext's lack of support for import.meta than Parcel.

I also noticed that import.meta was added to the language specification. Among modern browsers, all the major ones seem to support it as of 2020 without caveats.

I took note of #3639 but didn't find a solution there.

[willdurand]

I took note of #3639 but didn't find a solution there.

That's because we are unable to detect ESM but I am not too sure. Did you try to use a popup.mjs file instead?

[pieterdd]

I did indeed. Here is the exact change I tested. The lint output of rm -rf dist && yarn build && yarn web-ext lint -s build is still the same:

Validation Summary:

errors          1              
notices         0              
warnings        0              

ERRORS:

Code              Message                   Description                                    File                Line   Column
JS_SYNTAX_ERROR   JavaScript syntax error   There is a JavaScript syntax error in your     popup.8fd6e017.js   1      1021  
                   (Parsing as script       code, which might be related to some                                            
                  error: Cannot use         experimental JavaScript features that aren't                                    
                  'import.meta' outside a   an official part of the language                                                
                  module at line: 1 and     specification and therefore not supported                                       
                  column: 1021)             yet. The validation cannot continue on this                                     
                                            file.                                                                           
error Command failed with exit code 1. 

[willdurand]

popup.8fd6e017.js

It looks like your bundler still outputs .js files.

[pieterdd]

Good point. web-ext lint can't know what happens before bundling, and Parcel isn't aware that the .mjs extension should be preserved for web-ext lint to work.

I'll ask the Parcel team if preserving the extension would be an option for them. If not, is there any other way I can indicate to web-ext lint that it's a module file?

[willdurand]

I'll ask the Parcel team if preserving the extension would be an option for them. If not, is there any other way I can indicate to web-ext lint that it's a module file?

There has been work to do this in the past but I am not sure that led anywhere (#4020). We know this is a (annoying) limitation, though.

[pieterdd]

I had a couple of ideas but none of them seem actionable yet. They were:

• Some kind of ESLint-style annotation to silence a particular occurrence of a lint error (isn't an option because Parcel rightfully strips comments during minification)
• The linter could check that every place where the script is invoked carries a type="module" (may not be reliable, seems overly complex)
• Implement extra command line flag for the linter that optionally silences these errors (may silence legitimate errors)

Anyway, thank you for helping me understand what's going on. I'll check if there's anything that can be done from Parcel's end.

[pieterdd]

Good news, it's solvable from Parcel's end. There's no need to adapt the linter for my case.

[fregante]

I think this issue should still be solved here. If the extension works in the browser, then the bug is web-ext’s

[lucaseverett]

My extension was actually removed from addons.mozilla.org yesterday because of this issue.

My workaround since this first happened in April has been to manually rename files to .mjs after build, and that worked until a manual review, when I got a notice that the build no longer matched the submitted extension. I explained the situation, but that didn't help, and the extension was removed.

I tried the workaround mentioned by @pieterdd, but it didn't work for me. I get an error at build that I haven't been able to solve yet.

I concur with @fregante. I have a fully functional addon, and I don't think I should have to change my addon to work around a linter issue. And now my addon is unavailable because of it.

[pieterdd]

I'll reopen it if you feel strongly about it, but I (being the person who originally started the thread) can live with the workaround so I'll unsubscribe from the thread.

[Rob--W]

We'll accept a patch that falls back to re-interpreting the file as a module script when the error clearly indicates that the script fails due to the use of import.meta.

[lucaseverett]

We'll accept a patch that falls back to re-interpreting the file as a module script when the error clearly indicates that the script fails due to the use of import.meta.

Awesome! I just submitted a patch for review!

[ioanarusiczki]

@willdurand Sorry not noticing this issue earlier, could you add some str for qa in case I can check on this?

[ioanarusiczki]

@willdurand You don't have to, I took an example of import.meta from here

Before the fix, on linter 5.9.0 I got the error described above

Right now with 5.13.0 same testing sample passed validation

I attached the zip file I've tested with.
importmeta.zip

[willdurand]

@willdurand You don't have to, I took an example of import.meta from here

Ha, excellent! Thank you for verifying the issue.