Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Closed
wants to merge 1 commit into from
Closed

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

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 Replace non-inclusive terms used in configuration of jest-validate #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
Member

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

@wojtekmaj
Copy link
Contributor Author

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
Copy link
Member

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

@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
This was referenced Mar 13, 2021
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants