-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Conversation
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
Alright - updated the code to skip this change. Now it's all in jest-validate only.
Sure you can count on me :) |
@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? |
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. |
Summary
Part of #10235.
recursiveDenylist
option as an alternative torecursiveBlacklist
injest-validate
. Does NOT removerecursiveBlacklist
option. It will continue to work, unless overwritten withrecursiveDenylist
, to which I've given the priority.recursiveBlacklist
(in favor of the newly added option).Changes internal calls tovalidate()
to use new config (Maintainers: I'm not sure if that's a good idea - can you please advise? Should we expectjest-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 whererecursiveBlacklist
option was used, in two cases:recursiveBlacklist
optionThe former was left intact, and copied 1:1 over to create a new test, testing whether
recursiveDenylist
beaves exactly the same asrecursiveBlacklist
.The latter was updated to use
recursiveDenylist
.Tests were ran successfully.