feat!: use URLPattern for request matching
#2209
Draft
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.
Important
Please consider some of
URLPatternflaws before introducing it to MSW. We might also consider@remix-run/route-patterninstead as it's backed into Remix 3, provides great feature set, doesn't have theURLPatternshenanigans and overall looks extremely promising.Warning
As much as I hate this, this is a breaking change. Some of your existing handlers may start matching differently if they contain one of the dropped features (path params merging or trailing slashes). Even if this is a change for the better, this should land in v3.0.
This also significantly improves the test coverage for path matching in MSW.
This change does not intend to support
URLPatternas the input. For now, we will use it as internal mechanism (thus a polyfill version). Once the API gains global browser support, we may consider shipping an input support.Changes to document
/:a/foo/:a. Not a thing in the HTTP spec. They are supported bypath-to-regexpbutURLPatterndecided not to implement them and stick closer to the spec./foohandler will not match a/foo/request, and vice versa. I think MSW should respect thatURLPatternbehavior too to bring wider adoption of the API and be spec-compliant.Roadmap
/foo/:a/bar/:asyntax throws inURLPattern. Multiple same-named groups within the same URL component whatwg/urlpattern#226. Doesn't throw inpath-to-regexpand current MSW. Don't want to make a breaking change out of this.URLPatterndoesn't.