-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Lodash: Refactor away from _.escapeRegExp()
#43629
Conversation
Size Change: +29 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code changes LGTM 🚀
The only difference I can see with respect to the lodash function is that the lodash function will return ''
if the original string is undefined
, while the new version from this PR will just error.
Should we add that fallback too?
Good spot - however, I intentionally didn't add that fallback. First - I didn't notice the need for that, since we always had strings passed. If I was creating an exported utility function, maybe we would have handled that scenario, but I think it's unnecessary here. But most importantly - I believe handling unexpected types in combination with the untyped codebase makes it the ultimate hell for following through code and ensuring no bugs occur. By removing the extra ambiguity that the handling of the non-string values was adding, we solve part of the problem, and then we can hope to type the entire codebase to fully get rid of such cases. |
I agree with your views — was just flagging it for review completeness' sake :) Thank you! |
What?
This PR removes the
_.escapeRegExp()
usage completely and deprecates the function.Why?
Lodash is known to unnecessarily inflate the bundle size of packages, and in most cases, it can be replaced with native language functionality. See these for more information and rationale:
@wordpress/api-fetch
package haslodash
as a dependency #39495How?
Usages are just a few, so we're either creating a custom inline function that we reuse or directly running the replacement when it's more convenient to do it inline. It might feel repetitive to do this a few times throughout the codebase, but for a one-liner function, it's definitely better to do it that way rather than introducing yet another helper function into yet another dependency package.
Testing Instructions
npm run other:changelog