Bug: ESLint class should not load plugins already defined in plugins

[fisker]

Environment

Node version: v16.9.1
npm version: v7.9.0
Local ESLint version: v7.32.0
Global ESLint version: Not found
Operating System: win32 10.0.19043

What parser are you using?

Default (Espree)

What did you do?

import {ESLint} from 'eslint'

new ESLint({
	baseConfig: {
		extends: [
			'plugin:foo/preset',
		],
	},
	plugins: {
		foo: {
			configs: {
				preset: {}
			}
		}
	}
})

What did you expect to happen?

No errors.

What actually happened?

The config-array-factory is trying to load the plugin that I've set in the plugins.

node:internal/modules/cjs/loader:933
  const err = new Error(message);
              ^

Error: Failed to load plugin 'foo' declared in 'BaseConfig': Cannot find module 'eslint-plugin-foo'
Require stack:
- CWD\__placeholder__.js
Referenced from: BaseConfig
	// ...

Participation

• I am willing to submit a pull request for this issue.

Additional comments

N/A

[nzakas]

Strange this is only popping up now. Did this used to happen with CLIEngine?

[fisker]

I don't know, never used plugins before.

[mdjermanovic]

CLIEngine didn't have a constructor option that accepts plugin implementations, but an instance method CLIEngine#addPlugin. As building a config array for baseConfig happens right away during new CLIEngine(), I believe this functionality didn't exist - it wasn't possible to define plugin:foo/preset in baseConfig and provide the foo plugin as an object instead of loading it from the file system.

[fisker]

If we add plugins to the CLIEngine constructor, we can init additionalPluginPool with the plugin implementations, will it solve the problem?

IDK how CascadingConfigArrayFactory works, just an idea.

[mdjermanovic]

If we add plugins to the CLIEngine constructor, we can init additionalPluginPool with the plugin implementations, will it solve the problem?

I think something like that would work. In the current version, we are updating additionalPluginPool on the instance, but that's too late for extends in baseConfig.

eslint/lib/eslint/eslint.js

Lines 435 to 454 in e3cd141

	const processedOptions = processOptions(options);
	const cliEngine = new CLIEngine(processedOptions);
	const {
	additionalPluginPool,
	configArrayFactory,
	lastConfigArrays
	} = getCLIEngineInternalSlots(cliEngine);
	let updated = false;
	/*
	* Address `plugins` to add plugin implementations.
	* Operate the `additionalPluginPool` internal slot directly to avoid
	* using `addPlugin(id, plugin)` method that resets cache everytime.
	*/
	if (options.plugins) {
	for (const [id, plugin] of Object.entries(options.plugins)) {
	additionalPluginPool.set(id, plugin);
	updated = true;
	}
	}

We could instead pass additionalPluginPool map to the constructor. CLIEngine is now an internal module, so new options on it wouldn't be public.

[nzakas]

We shouldn’t be making any further changes to CLIEngine at this point, as it will be going away. We need to start transitioning functionality into the ESLint class directly.

[nzakas]

I took a look at this and updating CLIEngine is probably the easiest way to fix this.

[mdjermanovic]

I'm working on this.