ESLint should adhere to ignore rules that wrap import() and import.meta

The version of ESLint you are using.

Latest (5.x.x at time of writing)

The problem you want to solve.

// eslint-disable-next-line
const module = import('./foo.js');

This line should be skipped rather than blow up with a parsing error.

Your take on the correct solution to problem.

ESLint could instead analyze my code for exclusion rules and then parse what remains. This would be the expected ignore behavior IMO, and not require a policy debate.

It seems totally reasonable to adopt only Stage 4 features, but on balance it seems completely unreasonable to not actually ignore this line. ESLint should consider a less pure solution that strikes a balance here. Folding in a transpile step via babel-eslint to make sure this ignore happens is not a good option. Ultimately I don’t care if this line is skipped, but to have all the proximal code become collateral damage is a bummer.

Thanks in advance for considering!

Related:

• https://github.com/eslint/eslint/issues/11486

Are you willing to submit a pull request to implement this change?

I’m not currently informed enough to know the level of effort here, so I can’t commit to making the change yet.

[not-an-aardvark]

Requiring both /* eslint-disable */ and /* eslint-disable */ would help with the second issue from https://github.com/eslint/eslint/issues/11514#issuecomment-473415680 in some cases, but would not address the first issue.

Currently, /* eslint-disable */ means “ESLint should suppress any errors reported for this section of the code”, not “ESLint should pretend this section of the code doesn’t exist at all”. (To illustrate the difference: If ESLint entirely ignored the line containing import in your example, then it would also start reporting errors about the variable module not being defined if the variable was used later.) So while I sympathize with the inconvenience of having ESLint fail on parsing errors, I’m not convinced that being able to use // eslint-disable to suppress parsing errors is a desirable goal in the first place. Unlike many other linters, ESLint does separate passes for parsing and linting (this makes it possible to support arbitrary custom parsers and rules), and so there is naturally a fundamental difference between parsing errors and other types of linting errors. I’m not sure having eslint-disable comments conflate the two is a good idea.

One could imagine having a separate type of directive that does what you’re asking (i.e. it strips out sections of code before the code gets parsed). But it seems to me that it would almost always be better to use a different parser that handles the case you want, rather than adding directives to slice that case out of the code before linting.

[platinumazure]

@johanneswilm As has been noted multiple times in this issue, you can use the babel-eslint parser to have ESLint work with that syntax.