refactor: rename blacklist to blocklist and whitelist to allowlist

[mfederowicz]

related to #690

I thougt that rename Whitelist to Allowlist and Blacklist to Blocklist (all variable of course respect lower case and upper case)

I dont have any idea how to implement deprecation for old &rule.ImportsBlacklistRule{}, one idea is that to leave empty ImportsBlacklistRule and throw info about deprecation what you think @chavacava

ps. i checked other repos in github with &rule.ImportsBlacklistRule{} and there are 75 repos matching, so we dont have any simple solution :(

[mfederowicz]

Hmm i have idea to add list with deprecated rules and then remove deprecated rules in parseConfig method. I know that is quick and ugly sollution, but better solution will be implement versioning with deprecations list or something like that

[chavacava]

Hi @mfederowicz thanks for the PR.
I propose to do these changes in two steps:

1. Remove white and black list names from the internal code
2. Remove white and black list names from the external interfaces (config)

Use this PR for the step 1 (the easy one) and discuss how to go on with step 2

[mfederowicz]

ok @chavacava i cleaned up code from my changes related with deprecatedRules list, now there are only changes related with removing white and black lists (of course ImportsBlacklistRule was reverted to old state from master)

now iam listening sugestions/ideas how to remove black list from the external interfaces (config), white list luckly was used only in lists internaly (not in config or dedicated rules)

[chavacava]

@mfederowicz I've left some comments in the PR.
Please keep in mind that changing the name of a rule is a breaking change (users might need to modify configurations ) As I proposed, this PR should include only internal naming changes.

[chavacava]

Side note: changing the failure messages could be also considered as a breaking change because users might rely on failure messages thus changing them will force users to update their code.
Do not worry, I'm okay with the new messages you pushed, my note is just to highlight that managing "breaking changes" is a big deal :)

[denisvmedia]

my note is just to highlight that managing "breaking changes" is a big deal :)

We'll have to put some release notes on that, I think.

[mfederowicz]

@chavacava what is the status, any new sugestions?

[chavacava]

@chavacava what is the status, any new sugestions?

As I commented before, the PR (still) has renamed rules (the imports-blacklist rule renamed as imports-blocklist)
Changing the rule's name is a breaking change and my understanding was we agreed on not introducing breaking changes in this first phase of refactoring.

[mfederowicz]

@chavacava what is the status, any new sugestions?

As I commented before, the PR (still) has renamed rules (the imports-blacklist rule renamed as imports-blocklist) Changing the rule's name is a breaking change and my understanding was we agreed on not introducing breaking changes in this first phase of refactoring.

yes but imports-blocklist is new file not rename old one. I can revert testdata for test/import-blacklist_test.go and testdata/imports-blacklist-original.go but this dont have affect to old code :)

[chavacava]

yes but imports-blocklist is new file not rename old one. I can revert testdata for test/import-blacklist_test.go and testdata/imports-blacklist-original.go but this dont have affect to old code :)

Does that mean we will have two rules for the very same check?

[mfederowicz]

ok @chavacava i mean that I created copy of blacklist rule. Now I reverted tests/testdata for blacklist, and add separated test/testdata for blocklist. In near future we should remove Blacklist rule and add some notes about breaking change. If you (user) use development version of package you must know that changes are part of your live :P