Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaking: require meta for fixable rules (fixes #13349) #14634

Merged
merged 2 commits into from Aug 5, 2021
Merged

Conversation

@mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented May 26, 2021

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

fixes #13349 (implements the final step 3)

ESLint v7 requires that a rule that produces fixes must provide meta.fixable property, but only if the rule provides meta. In other words, rules that don't provide meta were allowed to produce fixes.

After this change (ESLint v8.0.0), ESLint will require that a rule that produces fixes must provide meta and meta.fixable. Otherwise, an error will be thrown in runtime.

This applies to legacy-format rules, too. Basically, all fixable rules must be converted to the new format.

What changes did you make? (Give an overview)

  • Changed the check in Linter.
  • Removed the check from RuleTester (added in #13489 as step 2) because it's no longer necessary.
  • Updated the related test case, and added one with a legacy-format rule.
  • Updated some unrelated test rules that didn't provide meta.

Is there anything you'd like reviewers to focus on?

Is there anything that should be updated in the documentation? I think that wording from #13493 already covers this.

Copy link
Member

@btmills btmills left a comment

Implementation looks good. One suggestion about changing the error message to match the new behavior.

@@ -919,7 +919,7 @@ function runRules(sourceCode, configuredRules, ruleMapper, parserOptions, parser
}
const problem = reportTranslator(...args);

if (problem.fix && rule.meta && !rule.meta.fixable) {
if (problem.fix && !(rule.meta && rule.meta.fixable)) {
throw new Error("Fixable rules should export a `meta.fixable` property.");
Copy link
Member

@btmills btmills May 31, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we throw an error in Linter rather than just RuleTester, "must" seems appropriate here. This wording will match #14573 as well. I'd also be fine extending the message to specify "code" and "whitespace" as allowable values.

Suggested change
throw new Error("Fixable rules should export a `meta.fixable` property.");
throw new Error("Fixable rules must set the `meta.fixable` property.");

Copy link
Member Author

@mdjermanovic mdjermanovic Jun 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestions! I'll fix this.

I'd also be fine extending the message to specify "code" and "whitespace" as allowable values.

Maybe we could also add the validation that the value is indeed "code" or "whitespace"? That wasn't discussed in #13349, and we're currently not using "code"/"whitespace" for anything, but since we're already making a breaking change this might be a good time to align the rules with the specification (and maybe we will use "code"/"whitespace" in the future to optimize autofixing).

Copy link
Member

@btmills btmills Jun 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The earliest mention I could find of fixable is #5417 (comment). Since we haven’t started using it in five years, I’m not sure starting to enforce it strictly with a validation error now has a corresponding benefit to make the breaking change worth it.

Copy link
Member Author

@mdjermanovic mdjermanovic Jun 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The earliest mention I could find of fixable is #5417 (comment). Since we haven’t started using it in five years, I’m not sure starting to enforce it strictly with a validation error now has a corresponding benefit to make the breaking change worth it.

Agreed!

Changed the error message per suggestions in 7a983f9

@mdjermanovic mdjermanovic requested a review from btmills Jun 10, 2021
Copy link
Member

@btmills btmills left a comment

LGTM!

nzakas
nzakas approved these changes Jun 17, 2021
Copy link
Contributor

@snitin315 snitin315 left a comment

Looks good!

@nzakas nzakas merged commit 4a7aab7 into master Aug 5, 2021
14 checks passed
@nzakas nzakas deleted the issue13349-step3 branch Aug 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

5 participants