Which packages would you like to change?
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 in eslint/core, then @types/eslint can always import those to keep things in sync.)
Participation
Additional comments
No response
Which packages would you like to change?
@eslint/compat@eslint/config-array@eslint/migrate-config@eslint/object-schemaWhat 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/corewill 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/eslintwith 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/eslintcan always import those to keep things in sync.)Participation
Additional comments
No response