feat: upgrade path-to-regexp #216
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This upgrades path-to-regexp to the latest version. The behaviour has changed quite a lot since the previous version we were using. Some examples of what has changed: - Wildcards are now subpatterns, e.g. `/foo/(.*)` rather than `/foo/*` - Delimeters are parsed everywhere (`http://foo` would think `://foo` or something is a parameter) - Characters need escaping, e.g. `foo?bar` must be `foo\\?bar` since you can now have optional parameters like `/foo/:bar?` To account for this in the most backwards compatible way possible, this change does the following: - Detects `://` in URLs and escapes it to `\\://` - Detects `/*` in URLs and converts it to `/(.*)` - **Breaks URLs with unescaped query strings** (i.e. `foo?bar` will no longer behave the same. you _must_ escape, `foo\\?bar` The breaking change with query strings is because we can't really reliably replace `?` automatically with `\\?`, since consumers may legitimately want to use the new optional parameters functionality.
|
Thanks for taking the time! |
|
When reading this in hindsight, it seems I totally glossed over the breaking changes bits of this PR when it was merged, as I would otherwise have made sure to release a new major version, both Nise 6 and Sinon 18, when this was merged. I must have been in a hurry 🙈 This requires updates to the documentation of both Sinon and Nise, as well. It's a bit late to revert, so we could add a config flag to 17 do the automatic conversion to the old format for query parameters? |
|
cc @mroderick |
|
no worries, my fault for not spotting that im guessing the escaping of we could basically say:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This upgrades path-to-regexp to the latest version.
The behaviour has changed quite a lot since the previous version we were using. Some examples of what has changed:
/foo/(.*)rather than/foo/*http://foowould think://fooor something is a parameter)foo?barmust befoo\\?barsince you can now have optional parameters like/foo/:bar?To account for this in the most backwards compatible way possible, this change does the following:
://in URLs and escapes it to\\:///*in URLs and converts it to/(.*)foo?barwill no longer behave the same. you must escape,foo\\?barThe breaking change with query strings is because we can't really reliably replace
?automatically with\\?, since consumers may legitimately want to use the new optional parameters functionality.Notes/questions
path-to-regexp, i.e. do no detection of backwards compat stuff, just tell consumers to use(.*)and escape:from now on. Thoughts?