suggestion: Move config types to DefinitelyTyped/eslint

[ST-DDT]

By moving the config types to https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/eslint (or one of its related repos) plugins/extensions that use typescript are able to augment the config without adding a third-party dependency.

(This only applies to the config types, not the defineConfig function that uses them)

[Shinigami92]

This repository does not have any plugin types anymore
Did you mean to address an issue in the other repo? https://github.com/eslint-types/define-config-plugin-types

[ST-DDT]

I'm referring to these types:

https://github.com/eslint-types/eslint-define-config/blob/main/src/config/index.d.ts#L14

[Shinigami92]

I think partially these are already included in @types/eslint but work slightly differently and are aimed more for plugin authors

The ESLintConfig is crafted for getting used in

eslint-define-config/src/index.ts

Line 10 in e6fa88d

export function defineConfig(config: ESLintConfig): ESLintConfig {

AND the most important part: they can be enhanced in eslint-define-config types with e.g.

eslint-define-config/src/parser-options.d.ts

Line 143 in e6fa88d

export interface CustomParsers {}

, which is a sub type of a property of ESLintConfig
And all this makes it possible to use global augmented properties which was released with v2

... so if you do not have specific mind-blown ideas of how to let that work all together, I can only sadly close this issue as "not planned" 😕

[ST-DDT]

I think partially these are already included in @types/eslint but work slightly differently and are aimed more for plugin authors

These types are almost identical:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/038dfbdd0e92572a4c80abf3f239a9fc458c6f71/types/eslint/index.d.ts#L885-L887 (I hope i found the right type here)

https://github.com/eslint-types/eslint-define-config/blob/main/src/rules/index.d.ts#L42-L45

One might have the CustomRules helper type, but otherwise they behave identical.
Are there any fundamental differences that prevent the usage of @types/eslint's types in the same way the are used here?

AND the most important part: they can be enhanced in eslint-define-config types with e.g.

Is there anything preventing the enhancement/augementation of eslint's config types itself?

... so if you do not have specific mind-blown ideas of how to let that work all together,

There is nothing mind blowing here. Just move the 4(?) "compatibility"/Custom* types to @types/eslint.

That way:

• you don't have to copy any eslint types here (reduce code duplication)
• the eslint-define-config types packages don't need a dependency to this package anymore
  • Which makes it easier/more likely for third-party repositories to adapt to because they don't need another dependency
• The @types/eslint repo can maintain it's own rule configs (Which still might be a manual task, same as it is now)

[Shinigami92]

Does @types/eslint even allow to run script to generate the types from eslint-schemas? Or do you not want to include the eslint rule types in that?

Please also notice that I don't like to have dependencies between @types/*/ts-type packages, but only devDependencies. Because you would then force the dev to download types, that they might not want.
So e.g. you want eslint-define-config but not @eslint/types, because the later one is right now only suited for plugin authors...

[ST-DDT]

Does @types/eslint even allow to run script to generate the types from eslint-schemas?

What would prevent a commit containing the output of a script?
And even if there was something that did, then we still could move the types (without the eslint rules) upstream and improve the downstream ts project capabilities (without adding a new dependency).

Please also notice that I don't like to have dependencies between @types/*/ts-type packages, but only devDependencies. Because you would then force the dev to download types, that they might not want.

That wouldn't change.

[Shinigami92]

What would prevent a commit containing the output of a script?

Reviewers in DefinitelyTyped

And even if there was something that did, then you still could move the types (without the eslint rules) upstream and improve the downstream ts project capabilities (without adding a new dependency).

1. I assume I will do nothing right now, consider using we or refer to yourself pls
2. Instead of moving, I suggest to copy over in the first state

Please also notice that I don't like to have dependencies between @types/*/ts-type packages, but only devDependencies. Because you would then force the dev to download types, that they might not want.

That wouldn't change.

And there is the point were I don't get it anymore 🤔
I might understand something terrible wrong here, because if you currently suggest to take some of my written types and just copy them over to @types/eslint, why did you open an issue in eslint-define-config in the first place instead of opening a PR in https://github.com/DefinitelyTyped/DefinitelyTyped ?

---

Some more context and background story:

• eslint is written in plain JS
• eslint maintainers do not have capacity anymore and trying even to outsource rules that are mostly stylistic (that's why https://github.com/eslint-stylistic was born)
• eslint maintainers wants to focus on shipping a new config format called FlatConfig
• eslint maintainers thinks about to rewrite (parts) of eslint in Rust
• eslint maintainers want to extract js specific rules into @eslint/js (not sure if these are just the rules and settings or a bit more than that)
• eslint-define-config got split into several type packages, because:
  1. there were to many plugins that needed to be supported by just one person
  2. just to update the types of one plugin-type, it was needed to bump the whole version for that one package and users would need to update without being even affected / get changes
  3. support for plugin is now extendable dynamically and as a plugin author you can just register your types
• if eslint rewrites stuff in Rust, the @types/eslint package is not stable/safe to be used for eslint-define-config
• FlatConfig support in eslint-define-config was created and owned by @sxzz and is not managed by me
  so I don't care about this line:

  eslint-define-config/src/flat-config/index.d.ts

  Line 1 in e1f8f09

  import type { ESLint, Linter } from 'eslint';

• eslint did not want to take over and maintain defineConfig (due to focus on FlatConfig development and capacity), so they are satisfied with having this eslint-define-config package maintained by the community

I hope I did not forget something
I now highly suggest you take action and make steps in the direction of DefinitelyTyped, you are 100% free to copy over any types you want, but due to I assume this is not an issue with eslint-define-config anymore, I will close this issue now
Feel free to link your progress from DefinitelyTyped here, so FFR we can track the progress

[Shinigami92]

FFR: this issue inspired to create DefinitelyTyped/DefinitelyTyped#67505 👍
However, only JSDoc were introduced, no types were copied over or added