feat: Allow rules to specify languages they work on #135
Conversation
|
|
||
| The `languages` array will contain strings that identify the specific language plugins the rule is designed to work with. Each string follows the standardized format `"plugin/language"` to uniquely identify the language plugin. | ||
|
|
||
| For backward compatibility, if `languages` is not specified, the rule will be assumed to work with all languages. |
There was a problem hiding this comment.
How would one specify only javascript?
There was a problem hiding this comment.
And if they specify javascript, would that mean it wouldn't apply to Typescript files? It may not need to check anything Typescript specific, and so specifying Typescript might not be obvious, but could still be applied to ts files.
There was a problem hiding this comment.
The language would be "js/js" for JavaScript.
And yes, that would also mean TypeScript because it uses the same language implementation. So any rule that specifies it works with JavaScript would also work with TypeScript (or any other dialect that reuses the JavaScript language implementation).
There was a problem hiding this comment.
So would this explicitly endorse TypeScript, then? In other words, "js/js" would imply TS but not, for example, Flow?
There was a problem hiding this comment.
"js/js" implies anything that runs through the JavaScript language plugin, which includes TypeScript and Flow, and anything else that swaps in a custom languageOptions.parser.
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
There was a problem hiding this comment.
Pull Request Overview
This RFC proposes adding language metadata to ESLint rules to specify which programming languages and dialects they support. This enhancement addresses documentation needs for multi-language compatibility and enables better runtime error handling when rules are used with unsupported languages.
Key changes:
- Introduces a
languagesarray property in rule metadata to specify supported languages - Adds validation logic to check rule compatibility at runtime
- Maintains backward compatibility by defaulting to all-language support when not specified
|
|
||
| ### Implementation Approach | ||
|
|
||
| 1. Update the `RuleMeta` interface in `@eslint/core` to accept `languages`. Deprecate the `language` and `dialects` properties. Add `meta.docs.dialects` property. |
There was a problem hiding this comment.
The implementation step mentions adding meta.docs.dialects property but this property is not explained elsewhere in the RFC. Consider clarifying what this property is for and how it relates to the languages array, or remove it if it's not needed.
| 1. Update the `RuleMeta` interface in `@eslint/core` to accept `languages`. Deprecate the `language` and `dialects` properties. Add `meta.docs.dialects` property. | |
| 1. Update the `RuleMeta` interface in `@eslint/core` to accept `languages`. Deprecate the `language` and `dialects` properties. |
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
The suggested change is bogus. As for "Consider clarifying what this property is for", that makes sense, although it's explained in the related discussion in eslint/eslint#19462, and I'm not sure if Copilot bothered reading that.
There was a problem hiding this comment.
I don't think Copilot works great in documentation situations. I've found it often misses a lot of context.
| ### Implementation Approach | ||
|
|
||
| 1. Update the `RuleMeta` interface in `@eslint/core` to accept `languages`. Deprecate the `language` and `dialects` properties. Add `meta.docs.dialects` property. | ||
| 2. Update the `validateRulesConfig()` function in `lib/config/config.js` to validate each rule's `languages` property against the language specified in the `Config` instance. When a rule doesn't match the language, add to an array of invalid rules. When all validation is complete, if there is an array of invalid rules, throw an error. Normalize `"js/js"` to `"@/js"`. |
There was a problem hiding this comment.
[nitpick] The implementation description is dense and could be clearer. Consider breaking this into separate sub-points for validation logic, error handling, and normalization to improve readability.
| 2. Update the `validateRulesConfig()` function in `lib/config/config.js` to validate each rule's `languages` property against the language specified in the `Config` instance. When a rule doesn't match the language, add to an array of invalid rules. When all validation is complete, if there is an array of invalid rules, throw an error. Normalize `"js/js"` to `"@/js"`. | |
| 2. Update the `validateRulesConfig()` function in `lib/config/config.js`: | |
| - **Validation Logic**: Validate each rule's `languages` property against the language specified in the `Config` instance. If a rule's `languages` property does not match the specified language, mark it as invalid by adding it to an array of invalid rules. | |
| - **Error Handling**: After completing the validation for all rules, check if there are any invalid rules in the array. If so, throw an error with a descriptive message listing the invalid rules. | |
| - **Normalization**: Normalize the `"js/js"` string to `"@/js"` to ensure compatibility with the current JavaScript language definition. |
Copilot uses AI. Check for mistakes.
|
Moving to final commenting. |
|
The final commenting period has ended, so merging. |
Summary
This RFC proposes adding metadata to ESLint rules that indicate which programming languages and language dialects they support. This will enable better documentation and runtime capabilities for ESLint when working with multiple languages.
Related Issues
Refs eslint/eslint#19462