Cannot use different configs for different instances

[jaythomas]

After some tests, I found that eslint-loader accepts only the first configuration object passed to the loader 'eslint-loader?{ configFile: "eslint.yaml" }'.

Use case: I'm attempting to use a different configFile for linting my .spec.js files vs my .js files (so that I can enable specific es6 and plugin rules for one and not the other), however, eslint-loader seems to carry over the configFile set from one loader instance to the other. So, for instance, if I set semi-colons to always in one file but never in the other, whichever config gets set first that config's settings for that rule will be enforces for both loaders.

Here is an example config in which the error can be replicated. Given eslint.yaml exists and foobar.yaml points to a non-existent files:

preLoaders: [
  {
    test: /\.spec\.js$/,
    loaders: [
      'eslint-loader?{ configFile: "foobar.yaml" }'
    ],
    exclude: [
      /bower_components/,
      /vendor/
    ]
  },
  {
    test: /\.js$/,
    loaders: [
      'eslint-loader?{ configFile: "eslint.yaml" }'
    ],
    exclude: [
      /bower_components/,
      /vendor/,
      /\.spec\.js/
    ]
  }
]

Expected behavior: webpack should show the following error:

ERROR in ./app/test.entry.spec.js
Module build failed: Error: Cannot read config file: foobar.yaml
Error: ENOENT: no such file or directory, open 'foobar.yaml'

Actual behaviors: it still loading the first config

ERROR in ./app/test.entry.spec.js
./app/test.entry.spec.js
  15:12  error  Extra semicolon                                            semi
  17:2   error  More than 1 blank line not allowed                         no-multiple-empty-lines
  20:2   error  Too many blank lines at the end of file. Max of 0 allowed  no-multiple-empty-lines

Changing the syntax around doesn't seem to make a difference either:

• Setting one loader as a loader and another as a preLoader - same results
• Setting one config to the default configFile name and not specifying a configFile name in that loader - same results
• Using "loader" property string instead "loaders" array - same results

  {
    ...
    test: /\.js$/,
    loader: 'eslint-loader',
    query: {
        { configFile: "eslint.yaml" }
    }
    ...
  }

• Using ESLintLoader module - same results

var ESLintLoader = require('eslint-loader')
  {
    ...
    test: /\.js$/,
    loader: ESLintLoader,
    query: {
        { configFile: "eslint.yaml" }
    }
    ...
  }

Conclusion: eslint-loader is not accepting any change after the configuration has been set in the first eslint-loader's loader.

After spending hours, I am not able to find any workarounds either. Thank you in advance for any responses. If you need any more details I'll be happy to update my comments.

Update 1: a nasty workaround

• Using a cloned eslint-loader module - works
  1. Copy node_modules/eslint-loader folder to node_modules/eslint-loader2
  2. Add eslint-loader2 to tests loaders array as eslint-loader2?{ configFile: "eslint.test.yaml" }
  3. Done.

Update 2

I have updated my config example above per @DiscoNova's comments.

[MoOx]

Hi, thanks for the great explanation.
I was surprised to see this shitty behavior.
Your comment seems longer that the code of this loader itself.
If you looked into the source, you will have found the error pretty quickly.

https://github.com/MoOx/eslint-loader/blob/7fce872132eb4853eff103fa243c4c51f1035910/index.js#L141-L143

This part of the code ensure on engine only is started. One should be started for a given config. Improvement should be easy to handle by making a hash from the config object and creating an engine per config hash.

PR welcome! If you need a hand, this might help https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github

[DiscoNova]

Without looking at the code, my instinct would tell me that the preloader configuration is selected based on the first match of test-regexp. Because of this, and the fact that the preloader configurations are listed in the order they are on the example, I don't think this is actually a bug; every ".spec.js" will match the earlier ".js" test.

Easy workaround would probably be to just reorder the configurations in the array; more specific ones first, less specific ones later. Harder workaround would mean that the code would need to check "how specific match we got on the test" and based on that, pick the most specific one ... and this could potentially lead to some very hard to debug issues (because developers are generally not good at writing regular expressions:)

Just my 2c ... I may have misunderstood the problem description; if so, please disregard my comment.

[jaythomas]

@DiscoNova, you are not wrong about the configuration ordering in my example above being wrong. I can assure that I have, however, been testing it with the spec loader first and have been able to log the results from both loaders. I have updated my example above and I have put in a pull request that resolves what I found to be the real issue.