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

Add support for `recursiveDenylist` option as an alternative to `recursiveBlacklist` #10236

Closed
wants to merge 1 commit into from

Conversation

@wojtekmaj
Copy link
Contributor

@wojtekmaj wojtekmaj commented Jul 3, 2020

Summary

Part of #10235.

  • Adds support for recursiveDenylist option as an alternative to recursiveBlacklist in jest-validate. Does NOT remove recursiveBlacklist option. It will continue to work, unless overwritten with recursiveDenylist, to which I've given the priority.
  • Updates documentation not to mention recursiveBlacklist (in favor of the newly added option).
  • Changes internal calls to validate() to use new config (Maintainers: I'm not sure if that's a good idea - can you please advise? Should we expect jest-config, say, v26.2 work with other dependencies @ v26.1 at all times? Shall I roll that back and add it as a TODO to #10235 instead? TIA)

Motivation

Part of continuous effort to get rid of non-inclusive terms like "whitelist" and "blacklist" implying that white = good and black = bad.

Test plan

jest-validate had one suite where recursiveBlacklist option was used, in two cases:

  • test the very recursiveBlacklist option
  • test for warning against unknown config options

The former was left intact, and copied 1:1 over to create a new test, testing whether recursiveDenylist beaves exactly the same as recursiveBlacklist.

The latter was updated to use recursiveDenylist.

Tests were ran successfully.

obraz

@SimenB
Copy link
Collaborator

@SimenB SimenB commented Jul 3, 2020

Should we expect jest-config, say, v26.2 work with other dependencies @ v26.1 at all times?

Yes - people do weird updates in their lockfiles all the time. I'm down with changing docs, but all existing code must work the same. If you're up for it, a separate PR which removes the old name and cleans up would be great - I can add it to the milestone of the next major release and land it at that time

…rsiveBlacklist`

Related to #10235
@wojtekmaj
Copy link
Contributor Author

@wojtekmaj wojtekmaj commented Jul 3, 2020

Yes - people do weird updates in their lockfiles all the time.

Alright - updated the code to skip this change. Now it's all in jest-validate only.

If you're up for it, a separate PR which removes the old name and cleans up would be great - I can add it to the milestone of the next major release and land it at that time

Sure you can count on me :)

@SimenB
SimenB approved these changes Oct 19, 2020
@SimenB
Copy link
Collaborator

@SimenB SimenB commented Oct 19, 2020

@wojtekmaj I forgot this over summer holidays, sorry! I wanted to merge in master so the changelog entry is in the correct place but it seems you've deleted your fork. Could you restore it?

@wojtekmaj
Copy link
Contributor Author

@wojtekmaj wojtekmaj commented Oct 19, 2020

@SimenB - Yes, absolutely; I didn't seem to be able to restore this PR so I raised another one instead: #10649.

@wojtekmaj wojtekmaj closed this Oct 19, 2020
This was referenced Oct 26, 2020
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.

None yet

3 participants
You can’t perform that action at this time.