[rule] inclusive-language
See original GitHub issuePlease describe what the rule should do:
The rule should identify a list of terms that are not inclusive and offer suggestions for terms that are more inclusive and have similar connotation.
What new ECMAScript feature does this rule relate to?
None.
What category of rule is this? (place an “X” next to just one item)
[ ] Warns about a potential error (problem) [x] Suggests an alternate way of doing something (suggestion) [ ] Other (please specify:)
Provide 2-3 code examples that this rule will warn about:
const blacklist = []; // blacklist is not an inclusive term, the following terms offer similar connotation with a more inclusive inferred meaning. (blocklist, excludelist)
if(badActor) {
blacklist.push(badActor);
}
Why should this rule be included in ESLint (instead of a plugin)?
As a main source of linting javascript in the community, having this rule be central to how our community operates and is inclusive would set a precedent for others moving away from terms that are not inclusive and don’t offer safe spaces for people to work in.
Are you willing to submit a pull request to implement this rule?
Yes.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
Yes, there’s danger, and language is super complex, and maybe it doesn’t meet ESLint’s standard (although stylistic doesn’t do the problem justice). Still, whether something is complex doesn’t mean one shouldn’t try. I think ESLint could reach a broad audience and it would be super cool if ESLint took a stand on
blacklist
!To be clear; I think folks should use a meaningful name, and “whitelist” and “blacklist” isn’t actually describing what you’re using the list for. I just don’t think an eslint rule is the best way to make that change happen.