validator.js
validator.js copied to clipboard
validatorjs
Add aliases for blacklist/whitelist as blocklist/safelist
Describe the bug This is not a bug, however, my company has a policy that we need to use inclusive language in our code and our project got flagged for using the blacklist and whitelist functions from validator.
Would you be willing to export inclusive language aliases blocklist and safelist? That way your code is backwards compatible and we can import inclusive language versions of those two functions.
Thanks!
I agree this would be a nice feature but the project maintainers have shared their view on this in a past PR; https://github.com/validatorjs/validator.js/pull/1522 But maybe they have changed their minds or are more in favour if it's just an alias instead of deprecating the current white/blacklist terminology
We can creates aliases without removing the older approach to how things are done. Feel free to make a PR
I have already proposed this one a year ago or so and it got rejected, hope something has changed!
@fedeci This is different than the change you proposed because it is just adding aliases, not renaming everything.
Whatever your political views, at the end of the day, we are developers working at companies which enforce policies that are out of our control, and which we are unable to change even if we wanted to.
This PR is a reasonable compromise. It does not push an agenda. It does not prescribe that you must use one or the other. It offers a simple solution for those of us who are stuck with this policy, without making a statement. It's just a few aliases made available for use when forced to.
Yeah aliasing is backward compatible as it wont break any apps that have validator integrated
@stevensacks I was also adding aliases https://github.com/validatorjs/validator.js/pull/1522/files#diff-bfe9874d239014961b1ae4e89875a6155667db834a410aaaa2ebe3cf89820556R210-R230
I think there’s an important difference. You weren’t just adding aliases, you were suggesting deprecating the words blacklist and whitelist, renaming files, etc.
I am saying do not change anything. Do not take a stance one way or the other. Leave everything the same and only add a few aliases so that it can pass the eslint rule and company policies. If you want/need to use the “inclusive language” words, you can.
Deprecating code is exactly that, it means keeping it available in the codebase to maintain backward compatibiliy but suggesting users to use another function/variable. Deprecating a function doesn't necessarily mean that in the next major it will be removed but rather that in the future the function may no longer be available.
Let's not discuss the specifics but agree that we believe having aliases for more inclusive language is a benefit to this project.
Let's not discuss the specifics but agree that we believe having aliases for more inclusive language is a benefit to this project.
I second this. LGTM so as to help people that are stuck with the issue