ESLint version
HEAD
What problem do you want to solve?
Currently, a rule has no way to indicate if it works on any given language. This information would be helpful for two reasons:
- Documentation purposes - being able to see which JS rules have been updated to support TS syntax.
- Runtime purposes - automatically turning off rules that don't apply to the given language (for instance, turning off JS rules when linting CSS files)
What do you think is the correct solution?
In the 2025-02-20 TSC meeting, we discussed adding two properties to meta:
meta.language - a string, such as "javascript", "css"meta.dialects - an array of strings, such as ["javascript", "typescript"]
@JoshuaKGoldberg suggested merging both properties into a single object instead.
It's probably worth putting together an RFC that takes into account the two use cases (documentation and runtime) as well as finalizing what the meta info should look like.
Participation
Additional comments
No response
ESLint version
HEAD
What problem do you want to solve?
Currently, a rule has no way to indicate if it works on any given language. This information would be helpful for two reasons:
What do you think is the correct solution?
In the 2025-02-20 TSC meeting, we discussed adding two properties to
meta:meta.language- a string, such as "javascript", "css"meta.dialects- an array of strings, such as["javascript", "typescript"]@JoshuaKGoldberg suggested merging both properties into a single object instead.
It's probably worth putting together an RFC that takes into account the two use cases (documentation and runtime) as well as finalizing what the
metainfo should look like.Participation
Additional comments
No response