With language plugins, there a bunch of new type definitions that would be helpful to share from the start (for Language, SourceCode, etc.).
What do you think is the correct solution?
Because eslint/core will be the eventual home of runtime-agnostic ESLint APIs, I think it makes sense to start by creating this package to publish the types that are necessary for language plugins, and then slowly add more APIs and types over time as the rewrite unfolds.
(An alternate approach would be to update @types/eslint with this information, but that would create a dependency on DefinitelyTyped for publishing, which I'm not in favor of. If we publish types in eslint/core, then @types/eslint can always import those to keep things in sync.)
Participation
[X] I am willing to submit a pull request for this change.
Which packages would you like to change?
@eslint/compat
@eslint/config-array
@eslint/migrate-config
@eslint/object-schema
What problem do you want to solve?
With language plugins, there a bunch of new type definitions that would be helpful to share from the start (for
Language
,SourceCode
, etc.).What do you think is the correct solution?
Because
eslint/core
will be the eventual home of runtime-agnostic ESLint APIs, I think it makes sense to start by creating this package to publish the types that are necessary for language plugins, and then slowly add more APIs and types over time as the rewrite unfolds.(An alternate approach would be to update
@types/eslint
with this information, but that would create a dependency on DefinitelyTyped for publishing, which I'm not in favor of. If we publish types ineslint/core
, then@types/eslint
can always import those to keep things in sync.)Participation
Additional comments
No response