Ignore CommonJS exports in the named rule

[sindresorhus]

AVA comes with ES2015 using Babel built-in for tests, but we don't transpile the source files. This results in the tests using import, while helpers and sources uses require() and module.exports.

I ran the rule in my got project which uses module.exports, but import in the tests:

  test/arguments.js:3
  ✖  3:9  createServer not found in './helpers/server'  import/named

  test/error.js:3
  ✖  3:9  createServer not found in './helpers/server'  import/named

  test/gzip.js:4
  ✖  4:9  createServer not found in './helpers/server'  import/named

The import: https://github.com/sindresorhus/got/blob/67ee190881f4ba9c498708dc41c1d71c5b6039a2/test/arguments.js#L3

The export: https://github.com/sindresorhus/got/blob/67ee190881f4ba9c498708dc41c1d71c5b6039a2/test/helpers/server.js#L8

I think it would make sense to either ignore exports.foo/module.exports or provide an option for it.

Previous discussion: #30

// @jfmengels @jamestalmage

[sindresorhus]

I'd like to see the default rule ignore CommonJS or provide an option for doing so too.

[benmosher]

So import/ignore exists to serve this purpose to some extent, but it is configured by path instead of by file content, and notably it itself is ignored if the module obviously contains an export statement.

So you should be able to set the following setting in an .eslintrc:

---
settings:
  import/ignore:
    - node_modules  # this is the default but will be removed if the setting is explicitly defined
    - helpers/server

It is a setting instead of a rule option so that it applies to all rules that parse external modules.

[benmosher]

Also, it's currenly implemented as a regex on the fully resolved path; I think it might make more sense as something more glob-like. I think you may have some good perspective on this, looking forward to your feedback.

[sindresorhus]

@benmosher I don't want to manually ignore paths. I want to ignore anything CommonJS. With the ignore option I would have to add ignore info to every project instead of just to my shareable config.

[sindresorhus]

I'm working on including this plugin in XO which is a almost zero-config linter. Requiring config for every project would mean I would have to disable this rule for good.

[benmosher]

Yeah, I hear that. Initially it was done like this because parsing is expensive, and things like immutable and jquery can take a few seconds just to determine they should be ignored.

I don't know if you've been following the discussions in node-eps about determining whether a file should be parsed as a module or as a script, but all the excitement there is around exactly this problem.

That said, I recently added a regex that checks for anything that looks like an ES6 export to do the ignore-import/ignore-for-modules hack. It has been sufficiently performant against large modules, so something similar that instead checks for CommonJS assignment could perform an implicit ignore.

[sindresorhus]

It has been sufficiently performant against large modules, so something similar that instead checks for CommonJS assignment could perform an implicit ignore.

Yeah, that would be good enough for now until the node-eps discussion is resolved. I define all my module.exports at the top level, so a regex would be pretty accurate in my case.

[dtinth]

We’ve stumbled upon the same problem where this plugin complains when I import a CommonJS module. As a temporary workaround, I modified this plugin to ignore CommonJS module by modifying the ignore function inside node_modules/eslint-plugin-import/lib/core/ignore.js to do this before return false;.

  var k = require('fs').readFileSync(path, 'utf8')
  if (/module\.exports/.test(k)) {
    console.log('Skipping', path, 'as it is CommonJS module');return true
  }

[benmosher]

@dtinth yep, that's more or less what I expect to implement to resolve this. Just need to test and figure out how to introduce as a non-breaking change.

[benmosher]

FWIW, planning to use UnambiguousJavascriptGrammar-style module detection in v2. So instead of looking for CJS, if your module has no imports or exports, it will be ignored.

Would love to hear dissenting opinions, if any. Feels like an easy win, so I'm not sure if I'm missing something obvious in my excitement.

[sindresorhus]

@benmosher Sounds great!