Bug: `config-helpers` lacks a dependency on eslint required by exported types

[kirkwaiblinger]

Which packages are affected?

• @eslint/compat
• @eslint/config-array
• @eslint/config-helpers
• @eslint/core
• @eslint/mcp
• @eslint/migrate-config
• @eslint/object-schema
• @eslint/plugin-kit

Environment

See https://github.com/kirkwaiblinger/eslint-config-helpers-missing-eslint-dep

What did you do?

Attempted to use @eslint/config-helpers in TS code without eslint@9 also present.

What did you expect to happen?

Types exported by @eslint/config-helpers should be usable without requiring undeclared dependencies to be installed.

What actually happened?

Types exported by @eslint/config-helpers are erroneous if eslint@9 is not present.

Link to Minimal Reproducible Example

https://github.com/kirkwaiblinger/eslint-config-helpers-missing-eslint-dep

Participation

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

Additional comments

Essentially, @eslint/config-helpers has a type-level dependency on eslint, but it doesn't declare it as a dependency in package.json. This means that the exported type don't work without eslint being installed, and they're also broken if a version of eslint other than 9 is installed. I think that a peer dependency with appropriate dependency range is likely the solution. I'm not quite sure whether a peer dep is the solution, or whether the types need to be split off into a separate package in order to avoid circular dependencies or something.

This is a hindrance for making progress on typescript-eslint/typescript-eslint#11190, a pre-requisite for typescript-eslint/typescript-eslint#10935

[lishaduck]

Yeah, I hit this as well. I used pnpm's packageExtensions to fix it for me, but because I re-export types from @eslint/config-helpers, it's still broken.

I think that a peer dependency with appropriate dependency range is likely the solution. I'm not quite sure whether a peer dep is the solution, or whether the types need to be split off into a separate package in order to avoid circular dependencies or something.

Vitest does that, I've found it creates issues with Deno (denoland/deno#27544), so I'd advise against it. If you do go the peerDependency route, I'd ensure it's an optional peerDependency... and now that I think about it, is it even valid if eslint has a prod dependency instead of a peer? How would you satisfy that?
Yeah, I'd go with an @eslint/types package (I'm assuming we don't want a dependency on @eslint/core in @eslint/config-helpers, right? That'd be circular? Type-level dependency injection anyone? lol).

[fasttime]

I'm not quite sure whether a peer dep is the solution, or whether the types need to be split off into a separate package in order to avoid circular dependencies or something.

A peer dependency would make it very complicated to use @eslint/config-helpers with older versions of ESLint that do not include types. One reason defineConfig was created in a separate package was to enable users of these older ESLint versions to import defineConfig in their config files.

[kirkwaiblinger]

A peer dependency would make it very complicated to use @eslint/config-helpers with older versions of ESLint that do not include types. One reason defineConfig was created in a separate package was to enable users of these older ESLint versions to import defineConfig in their config files.

@fasttime to be sure I'm understanding correctly, do you mean this as a concern with a peer dep as the specific solution or with whether there is anything to be done here in the first place?

[nzakas]

The eslint package currently has @eslint/config-helpers as a dependency, so I don't think we can also go in the opposite direction.

I think the only real option is a package just for types, but that comes with a lot of headaches around coordination between this repo and the eslint/eslint repo.

[nzakas]

Looking at this a bit more deeply: the original plan was for @eslint/core to contain both the core types and core functionality for ESLint. In the short-term, I think it makes sense to use @eslint/core as the shared type package, it just needs updating with more types from the eslint package. Then, we can make both eslint and @eslint/config-helpers depend on @eslint/core.

If down the road we want to further subdivide @eslint/core into @eslint/core and @eslint/types, we can always revisit.

I'll work on this.