Inconsistent behaviour with `import/ignore`

[rhys-vdw]

Getting some strangely inconsistent behaviour with the import/ignore setting.

My config:

// .eslintrc.js
module.exports = {
  "settings": {
    "import/ignore": [
      "\.erb$",
      "\.coffee$",
      "node_modules"
    ],
    "import/resolver": {
      "webpack": {
        "config": "./config/webpack.config.js"
      }
    }
  },
// ... the rest is irrelevant

The erroneous errors:

> eslint --config .eslintrc.js app/assets/javascripts/


/Users/rhys/Projects/usability-hub/usability_hub/app/assets/javascripts/components/test-form/screenshots-editor/screenshots-editor.js
  12:37  error    Parse errors in imported module '../../../views/screenshot-hitzone-editor': Unexpected token %= (8:31)  import/namespace
  12:37  error    Parse errors in imported module '../../../views/screenshot-hitzone-editor': Unexpected token %= (8:31)  import/default
  12:37  warning  Parse errors in imported module '../../../views/screenshot-hitzone-editor': Unexpected token %= (8:31)  import/no-named-as-default
  12:37  warning  Parse errors in imported module '../../../views/screenshot-hitzone-editor': Unexpected token %= (8:31)  import/no-named-as-default-member

The file that that is throwing errors:

Lines 12 and 13 from screenshots-editor.js (the file containing failed imports above):

// ...
import ScreenshotHitzoneEditor from '../../../views/screenshot-hitzone-editor';
import RailsRoutes from '../../../rails-routes';
// ...

The reason why I'm showing both of these lines is because both of these references files are .js.erb files.

Line 8 from screenshot-hitzone-editor.js.erb:

// ...
const SCREENSHOT_MAX_WIDTH = <%= Screenshot::MAX_DISPLAY_WIDTH %>;
// ...

And the same erb syntax used in rails-routes.js.erb:

// ...
<%=
routes = [
  /^choose_test$/,
  /^confirm_destroy_response$/,
// ...

So ESLint will try to parse screenshot-hitzone-editor.js.erb, but will (correctly) avoid parsing rails-routes.js.erb. There are several erb files in the project, and this is the first time that this configuration strategy has failed.

Note that I can replace the import statements with fully qualified paths, and the same problem occurs:

// still fails:
import ScreenshotHitzoneEditor from '../../../views/screenshot-hitzone-editor.js.erb';
import RailsRoutes from '../../../rails-routes.js.erb';

So the problem does appear to be with eslint-import AFAICT.

I'm happy to help debug this.

[benmosher]

There is an unfortunate (but practical) compromise in import/ignore where it will parse ignored paths if they look like they hold exports (based on a regex). It's a fairly grimy bit that I'm very much looking forward to blowing away in v2.

You should be able to remedy this by specifying the import/extensions setting as ['.js'] (or whatever list of extensions you use with ES6 parseable files).

[rhys-vdw]

Thanks for the quick response, @benmosher.

You should be able to remedy this by specifying the import/extensions setting as ['.js'] (or whatever list of extensions you use with ES6 parseable files).

  "settings": {
    "import/extensions": [
      ".js",
    ],
    "import/ignore": [
      "\.erb$",
      "\.coffee$",
      "node_modules"
    ],
    "import/resolver": {
      "webpack": {
        "config": "./config/webpack.config.js"
      }
    }
  },

Sadly the above change to my .eslintrc.js did not resolve the issue! (Despite updating to 1.12.0)

it will parse ignored paths if they look like they hold exports (based on a regex)

This has given me a (fragile) workaround for now... I can use module.exports instead of export default.

[benmosher]

Yeah, it's not great. Sorry about that! I'm surprised you're the first one to hit this in a major way (and report it, anyway).

I'm startled that import/extensions didn't resolve this, though. It should be a hard whitelist, and should completely prevent any non-.js-ending file from being parsed. (and it was published in 1.7.0, looks like, from the changelog).

[benmosher]

Agh, okay. There is definitely a bug here. import/extensions is also subject to the hasExports regex, which was not my intent. Must have been an oversight that the tests don't cover.

This can be patched in v1, I will try to knock this out some morning this week.

[rhys-vdw]

@benmosher thanks for the quick and clear response, and, as always, thanks for the fantastic tool. Happy to work around this minor inconvenience. 👍