feat(eslint): add inclusive-language rule #71
Conversation
There was a problem hiding this comment.
The comments on unicorn.js point out the usage of "master" in URLs
Looking I found muenzpraeger/eslint-plugin-inclusive-language#1 (comment) which noted that "HEAD" could be used instead. IDK if all users have GitHub URLs but those are likely to be the bulk and others can add a eslint-disable-next-line if no other URL works
Might be good to update the URLs in unicorn.js in this PR
I fixed them in #70 by linking to tags, which actually is more correct since some of the links went 404 in the newer releases. |
|
@smackfu Thank you so much for your contributions! since we are encouraging the use of inclusive language, i'm proposing we use |
|
@infoxicator @nellyk I changed it to be an "error" instead of "warning". Thanks for the feedback! |
| @@ -1,3 +1,4 @@ | |||
| /* eslint-disable inclusive-language/use-inclusive-words */ | |||
There was a problem hiding this comment.
I'd prefer this be disabled just for the rule configuration section (as I'm guessing that's where there are errors) but we also want to get this feature out
There was a problem hiding this comment.
Fair point, I just figured all the lines in that section would need the exclusion which might make it less clear.
# [14.2.0](v14.1.1...v14.2.0) (2021-05-25) ### Features * **eslint:** add inclusive-language rule ([#71](#71)) ([5a1cf81](5a1cf81))
|
🎉 This PR is included in version 14.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
Adds the "inclusive-language/use-inclusive-words" rule:
https://github.com/muenzpraeger/eslint-plugin-inclusive-language
The list of words is explicit to reduce the chance of unintended changes from the upstream dependency.
The rule is currently marked as a warning. Not sure if an error would be warranted?
Please make sure that the PR fulfills these requirements
Motivation and Context
Using inclusive coding terms is essential to creating an inclusive environment. And anything that can be automatically tested by eslint should be.
How Has This Been Tested?
Ran
npm packand installed the repo against an existing repository that was using the existing lint config. After adding a violation to the code, running eslint generated the expected warning:Also, you can see the suggestions in WebStorm here:
Types of changes