Bug: cache doesn't invalidate on plugin version upgrade

[tdeo]

Environment

Node version: v16.15.1
npm version: N/A - using yarn
Local ESLint version: 8.23.0
Global ESLint version: no global eslint installed
Operating System: MacOS 12.5.1

What parser are you using?

@babel/eslint-parser

What did you do?

I upgraded eslint-plugin-react from 7.37.1 to 7.37.7.

Due to new rules addition and the cache for the former version still being used, offenses for those new rules weren't being reported.

My code contains the following:

const Componnent = () => {
  return <table>
    <thead>
      <th align="center">title</th>
    </thead>
  </table>
}

What did you expect to happen?

Offenses to be reported

What actually happened?

Nothing was reported

Participation

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

Additional comments

Should be fixed by this PR: eslint/eslintrc#88

[nzakas]

I think the only way we can guarantee this with the new config system is to ask plugin authors to include a version field in their plugin object, as we no longer know the package.json to read to get this info with the new config system.

[CSchulz]

I am wondering why we can't read the version out of the package.json file?

[nzakas]

@CSchulz because with flat config we don't have any package information. You are manually importing a package and then passing the object into the config. We don't know where that object came from inside of ESLint.

[CSchulz]

I think I did not get the point.

I have checked out the new experimental feature documentation and there is still the plugins array to put custom plugins.
The eslint core loads all plugins declared in the plugins array out of the node_modules, right?
like here?

eslint/lib/cli.js

Lines 132 to 144 in 740b208

	if (plugin) {
	const plugins = {};
	for (const pluginName of plugin) {
	const shortName = naming.getShorthandName(pluginName, "eslint-plugin");
	const longName = naming.normalizePackageName(pluginName, "eslint-plugin");
	plugins[shortName] = await importer.import(longName);
	}
	overrideConfig[0].plugins = plugins;
	}

[nzakas]

The eslint core loads all plugins declared in the plugins array out of the node_modules, right?

No. What you're looking at is the code that loads the plugins from the command line --plugin flag. That is not the standard way to load plugins. Please read the documentation for the new config system:
https://eslint.org/docs/latest/user-guide/configuring/configuration-files-new

[nzakas]

So I think we can use the same approach as in #16875, where we ask plugins to supply a meta property. @eslint/eslint-tsc what do you think?

[mdjermanovic]

So I think we can use the same approach as in #16875, where we ask plugins to supply a meta property

Sounds good to me 👍

If plugin exports meta.name (or top-level name), shall we use that name instead of its key from the config?

[nzakas]

If plugin exports meta.name (or top-level name), shall we use that name instead of its key from the config?

My idea was to combine the two, so js:@eslint/[email protected] if the plugin has meta information and just js if not.