fix(replace)!: do not escape delimiters#1088
Conversation
|
@guansss apologies for the delay in getting to your PR. it looks like there are a few conflicts to clean up since you submitted it. Please clean those up and we'll give this another look. @guybedford could you lend your eyeballs to this breaking change? |
BREAKING CHANGES: user is now responsible for escaping delimiters
54fa18b to
31361ce
Compare
|
Okay, I've rebased it onto master. |
guybedford
left a comment
There was a problem hiding this comment.
Great work. Looks solid to me. Is the escape function still used elsewhere or can it be removed?
This is a major change so we should bump the semver version.
|
Another thing that could be useful is accepting an actual regex for delimiters by value as well eg via |
|
Thanks @guybedford. Yeah, the The delimiters will end up being concatenated into a string to build the regex, so there may be no need to accept a regex. |
|
@guansss accepting a regex may still solve the original use case of supporting an unescaped input though! |
|
@guybedford that makes sense, but IMO it's more like a trick and could be easily done from user-side via something like |
|
@guansss at the end of the day manual regex escaping is work, and something that can be a cause of errors. Making things easier where possible without sacrificing maintainability is the goal in open source! |
|
@guybedford agreed, I'm not quite into it though!😄 |
Rollup Plugin Name:
replaceThis PR contains:
Are tests included?
Breaking Changes?
If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.
List any relevant issue numbers: #904
Description
Fixes #904, now delimiters given by users are no longer escaped, so it's possible to pass
['\\b', '\\b']to revert to the default behaviour prior to #903.It's breaking because users may have been relying on current behaviour (bug) to match special characters which are now required to be escaped.