Allow config overrides

[rogeliog]

This add the ability to pass a jest-runner-eslint.config.js file, with full support for https://eslint.org/docs/developer-guide/nodejs-api#cliengine

Fixes #11 and part of #10

[ljharb]

Ooh, nice!

[ljharb]

can you include some examples, especially ones that aren't all lowercase, or have multiple words?

[ljharb]

couldn't this instead be fix: true in cliOptions?

[rogeliog]

So my thought process was this: The ESLint Node api has a fix option but it works a bit different than --fix because it doesn't save to disk the result... In order to do that outputFixes() needs to be called.

One options that I thought is: "Always call outputFixes() when fix === true"... but I was a bit worried about it because then it would break the 1:1 mapping with the ESLint docs... If you think that is a better option I'm happy to change it 😄

[rogeliog]

Also, I agree that the writeOnFix feels a awkward so I'm happy to change it

[ljharb]

Since this is eslint command line options, and on the CLI, --fix definitely writes to disk, I think that cliOptions is the right place to put it.

In other words, cliOptions to me maps to what eslint on the CLI supports - what the eslint API supports won't actually matter to users.

[rogeliog]

Perfect, I agree!

[rogeliog]

@ljharb I wonder if it is even worth having it nested under cliOptions?

I originally did it so that it is a bit more feature proof in case we add options that do no map to cliOptions, but it might be an overkill

[ljharb]

Having been burned by this in the past, I think making cliOptions is definitely prudent, even if it's a bit annoying at times for users.

I'd much rather have an unneeded cliOptions, than need to add a new kind of option and have no place to put it :-)

[ljharb]

I think cliOptions should actually map to https://eslint.org/docs/user-guide/command-line-interface

[rogeliog]

I think that is a good point.

Even though it would be more work, because we need to make sure that we do the correct mapping of "pseudo CLI options" to API options, but it will definitely provide a better experience.

After looking at the docs here is the list of CLI options that we could have. It does not include all of them because the API does not accept all of them. Although a lower priority, but we might need to shim the rest

Proposed option	ESLint CLI option	Notes
noInlineConfig	--no-inline-noInlineConfig
cache	--cache
cacheLocation	--cache-location
config	--config
envs	--env	Needs to be pluralized because --env can be passed multiple times
exts	--ext	Needs to be pluralized because --ext can be passed multiple times
fix	--fix
globals	--global	Needs to be pluralized because --global can be passed multiple times
noIgnore	--no-ingore
ignorePath	--ignore-path
parser	--parser
parserOptions	--parser-options
plugins	--plugin	Needs to be pluralized because --plugin can be passed multiple times
rulesdirs	--rulesdir	Needs to be pluralized because --rulesdir can be passed multiple times
rules	--rule	Needs to be pluralized because --rule can be passed multiple times
noEslintrc	--no-eslintrc
exts	--ext	Needs to be pluralized because --exts can be passed multiple times

What do you think?

[ljharb]

I don't think they need to be pluralized; I think if they want more than one, it can be an array - like ext: 'foo' or ext: ['foo', 'bar']

[ljharb]

similarly, this should be config, since it should map to actual CLI options, and not to eslint's API (that very few users ever interact with)

[ljharb]

Seems good, thanks!