Optionally allow eslint inline configurations

[voxpelli]

The change made in #39, while intended to stop inline activation of rules, actually broke my runs (voxpelli/eslint-config#39), since I do inline deactivation of rules that doesn't apply to a specific file or line.

I wonder if there's a way to allow disabling rules without also allowing the enabling of rules 🤔

Simpler is probably to allow the original behavior, but make it an opt in (or opt-out)

Getting late here, so can't do a PR right now, but still wanted to make a note of it here right away, I can maybe find time for a PR another day.

[AriPerkkio]

Thanks for the improvement idea and sorry for breaking your tests @voxpelli.
Ignoring the inline configurations is indeed intended default functionality of eslint-remote-tester but I'm open for allowing overriding it via configuration.

I think the best way to fix this is to allow users specify linterOptions which would be given to new ESLint(linterOptions) here:

eslint-remote-tester/lib/engine/worker-task.ts

Lines 179 to 186 in 1e5e5ea

	const linter = new ESLint({
	useEslintrc: false,
	overrideConfig: config.eslintrc,
	// Only rules set in configuration are expected.
	// Ignore all inline configurations found from target repositories.
	allowInlineConfig: false,
	});

Default values of the linterOptions would be the current ones. User provided linter options would be shallow merged with default ones.

    const linterOptions: ESLint.Options = {
        useEslintrc: false,
        overrideConfig: config.eslintrc,

        // Only rules set in configuration are expected.
        // Ignore all inline configurations found from target repositories.
        allowInlineConfig: false,

        ...config.linterOptions,
    };

This way you could enable allowInlineConfig in eslint-remote-tester.config.js:

module.exports = {
    ...
    linterOptions: {
        allowInlineConfig: true,
    },
    ...

[voxpelli]

I agree @AriPerkkio, I'll make a PR 👍

No worries! I do know that I'm using this module from a different perspective than it was intended for, testing rule collections rather than individual rules 🙂