To eliminate duplication and avoid a breaking change.

Same here. Don't want to delete the type, just alias the new type instead.

This is the interface of eslintrc configs. I think this change should be made here instead:

Oops, good catch!

Otherwise, a configuration like "example/dollar-sign": ["error"] would be invalid.

Are you sure about that? RuleConfig is defined as follows:

https://github.com/eslint/rewrite/blob/37e3e14499c1d42c0c420dfbabac3a10a9a82925/packages/core/src/types.ts#L680-L682

To me, that reads like just having a severity would still be valid even without Partial?

To me, that reads like just having a severity would still be valid even without Partial?

It would be valid as the whole value, i.e., not wrapped in an array.

I was testing this way:

// eslint.config.ts

import type { RuleConfig } from "@eslint/core";

declare module "@eslint/core" {
	interface RulesConfig {
		"example/dollar-sign": RuleConfig<["always" | "never"]>;
	}
}

import { defineConfig } from "eslint/config";
//import example from "eslint-plugin-example";

export default defineConfig([
	{
		files: ["**/*.js"],
		//plugins: { example },
		rules: {
			"example/dollar-sign": ["error"],
		},
	},
]);

Ah, I see! It seems like we could modify RuleConfig like this:

export type RuleConfig<RuleOptions extends unknown[] = unknown[]> =
	| Severity
+       | [Severity]
	| [Severity, ...RuleOptions];

It would be one less thing rule developers need to remember?

https://github.com/eslint/rewrite/blob/37e3e14499c1d42c0c420dfbabac3a10a9a82925/packages/core/src/types.ts#L680-L682

Perhaps that should have been Severity | [Severity, ...Partial<RuleOptions>] so that rule types don't need to make options optional. Though that would assume that options are always optional, which doesn't necessarily has to be the case.

To have the eslint package import the ESM version of the @eslint/core types, it's also possible to use the resolution-mode import attribute, which is stable since TypeScript 5.3 according to the docs. That would be this change in lib/types/index.d.ts:

-} from "@eslint/core";
+} from "@eslint/core" with { "resolution-mode": "import" };

And in that case we'd probably need a new .mts test file to test the extendable interface inside an ESM module.

I tested this method and it passed both npm run test:types and npm run lint:types (after moving the new tests to an .mts file). I haven't checked the type integration tests though.

Ooh nice!

I suppose the question then is which TypeScript versions do we want to support?

Good question. Currently, we don't have a statement or policy that specifies which TypeScript versions are supported, unlike what we have for Node.js or jiti. I think it would be good to add this for TypeScript as well, regardless of which features we choose to support.

As far as I know, there's no reliable way to import types from an ESM module into a CommonJS module that works without resolution-mode. So, if we want to support TypeScript versions before 5.3, we'll need to stick to CommonJS-style core types. Alternatively, we could switch the ESLint types to ESM, but that would only make sense if we convert the whole repo to ESM.

Supporting a minimum TypeScript version is a lot less work than converting the package to ESM, so let's discuss that option:
#19920

Now that TypeScript < 5.3 is no longer supported and the CommonJS core types re-export the ESM types I think it should be fine to move forward with this PR. Some of the comments in this thread seem no longer relevant.