Following #18845 -> #18845 (comment) -> #18854 -> eslint/rewrite#106 (comment): now that ESLint publishes its own .d.ts TypeScript types, there are two packages consumers can pull ESLint from:

• eslint itself: which is now the correct place
• @types/eslint, as published by https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/eslint: which is now slightly outdated

Once a package publishes its own types, it's common practice for the DefinitelyTyped side to mark the the old @types/ package as a "stub" (no-longer-necessary) package. From https://github.com/DefinitelyTyped/DefinitelyTyped?tab=readme-ov-file#removing-a-package:

When a package bundles its own types, types should be removed from Definitely Typed to avoid confusion.

You can remove it by running pnpm run not-needed <typingsPackageName> <asOfVersion> [<libraryName>].

• <typingsPackageName>: This is the name of the directory to delete.
• <asOfVersion>: A stub will be published to @types/<typingsPackageName> with this version. Should be higher than any currently published version and should be a version of <libraryName> on npm.
• <libraryName>: Name of npm package that replaces the Definitely Typed types. Usually this is identical to <typingsPackageName>, in which case you can omit it.

DefinitelyTyped/DefinitelyTyped#70012 is a good example of another package that was migrated to TypeScript. @types/react-datepicker now has no .d.ts files in it. The package instead has an npm deprecation:

This is a stub types definition. react-datepicker provides its own type definitions, so you do not need this installed.

Is there anything blocking an enterprising individual from sending a similar PR to DefinitelyTyped to deprecate @types/eslint?