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
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants