Tools: 📎 Add `lint.disallowedWords` project config option

[sebmck]

We probably need to have a higher level discussion on the purpose of this rule, whether it should be renamed, the scope, etc.

[ematipico]

Two names that come to mind: preferredLanguage or suggestedLanguage

It's more positive and it's more clear than "confusing"

Regarding the scope, I live it to the people that are english native speaker :)

[yassere]

I know we want to have minimal configuration, but I don't think we should have a hard-coded list of English-only words that we apply to every project. Maybe rome init could populate our defaults, but each project could set up their suggestions in a way that works for them?

[sebmck]

@yassere Oh that'd be cool. I have been thinking around how we want to handle custom lint plugins, and having some lint project config options like:

• disallowedWords: What you're proposing we make the rule use
• disallowedPatterns: Basically what we pass into doesNodeMatchPattern
• disallowedModules: With inherited project configs you could disallow some heavy node module that's available in a parent folder from say, your website.
• ...

Would cover a ton of use-cases without us needing to commit to a plugin system yet. And even if we did eventually have plugins/custom rules, having it first-class would be valuable.

[sebmck]

Edited the issue title to reflect the new approach. I'll handle adding the disallowWords option as a reference and create issues for the others we might want for discussion and assignment.

[David-Else]

Hello, what is the purpose of this rule? Is it to disallow certain JS/TS keywords like var etc? Thanks, sorry to ask, I must be missing something obvious here.

[sebmck]

It's to disallow certain words inside of comments and identifier names. It doesn't effect keywords.

[David-Else]

@sebmck Cheers, but I don't see why anyone would want to do that? What is the use case?

[sebmck]

It's designed to replace this lint rule #267/#447.

[David-Else]

@sebmck I read those two links, and am shocked you just shut down the debate like that. I thought this was a linting tool, not a political or moral soapbox. This rule has nothing to do with software or coding and I strongly suggest you remove it to avoid unwanted controversy and alienation of potential users.

[sebmck]

@David-Else Literally the entire purpose of this issue is for discussing and implementing an alternative strategy. Are you trying to bait me? I don't know what it is that you want.

[David-Else]

@sebmck I am not trying to bait you! I don't know why you think that. I am just really into linting tools, that is why I am here reading the issues in an unreleased lint tool.

I like the look of this project and just want to give my opinion in this discussion. I think what I am saying is valid, I am saying that the idea of having a lint that does things like suggest you replace blacklist with denylist is a very bad one for the reasons I stated. I assume you disagree, which is fine.

[sebmck]

I am not trying to bait you! I don't know why you think that.

I read those two links, and am shocked you just shut down the debate like that. I thought this was a linting tool, not a political or moral soapbox.

Because you were deliberately inflammatory.

Linting is encouraging best practices, including things like checking for spelling and grammar. If you agree with that basic premise then providing a way to avoid using problematic words to create a more inclusive and healthy code and social environment fits in. After all, linting is about enforcing order for a more homogeneous codebase.

For a tool that prides itself in providing a more human interface than others, including when it comes to understanding and resolving issues, we have lowered the bar for what can be considered inconvenient and annoying. The error is automatically fixable so the "burden" for having it is not high.

If you are interested in what the existing error looks like:

The link included is https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/ and I would encourage you to read it if you haven't already. It is odd to characterize this as a political issue. Would you describe our decision to use hard tabs, being mainly motivated by accessibility to be advocating for another political or moral issue? #425.

I like the look of this project and just want to give my opinion in this discussion.

Yes and there are many issues here, which is why I assumed as your first participation in the project you probably knew what this issue was about to engage with it out of all of them.

[David-Else]

@sebmck I just wrote you back an essay of an answer, and then deleted it as I realized I was adding to the exact thing I am fundamentally against.

Software needs to be free of this awful polarized politics that has drained all the fun out of it. This is very much a political issue and is clearly highly diverse. Here is the evidence in the number and content of these comments on the subject:

https://www.reddit.com/r/programming/comments/hqpyuu/after_github_linux_now_too_avoid_introducing_new/
https://www.reddit.com/r/programming/comments/gy9yzs/go_has_removed_all_uses_of_blacklistwhitelist_and/
https://www.reddit.com/r/Liberal/comments/h9obc9/github_to_replace_master_whitelist_blacklist_and/
https://forums.theregister.com/forum/all/2020/06/15/github_replaces_master_with_main/

If you didn't think it was controversial you would not have watered it down from 'inconsiderate' to 'confusing' to 'disallowed'.

I wish the project well, but hope this anti-feature is scrapped.

[ljharb]

Using certain terms alienates users far more than avoiding certain terms, and there does not exist a part of life or software divorced from politics.

If being considerate of other humans takes the fun out of programming, i truly wish you luck finding a profession where “other people” aren’t a consideration.

[richardaum]

A great proposal here, indeed! :tada:

I've taken a look at the related issues mentioned along with the discussions and I've got some questions (probably related):

• Would those disallowed words be fixed or could they be provided/extended?

• I'm not sure if this is supposed to be a zero-config tool, but would you consider adding this as a global suppression through a config file?

It's also worthy to mention it could not only be related to frontend code. You could receive a disallowed word from backend and you kind of must keep using it:

const { data } = axios.get('...');
const { blacklist } = data; // would it suggest to rename the `blacklist` identifier?
filter(blacklist);
render(blacklist);

You could also rename it to look better, but you still need to make a reference to the disallowed word:

const { data } = axios.get('...');
const { blacklist: denylist } = data;
filter(denylist);
render(denylist);

[yufizan]

Tq,