Closed kettanaito closed 3 years ago
You can use a backslash to escape the :
for now, but there’s also ongoing work to standardize this protocol in chrome too with URL pattern: https://web.dev/urlpattern/. I probably won’t be making major changes until we standardize that spec a bit more and then back port some of the decisions.
Thank you for your quick reply, @blakeembrey.
I haven't heard about URL pattern support coming to the browsers—that sounds incredible.
Here I was writing down an abstract specification for URL patterns, which now may be premature. It'd still be great to have an implementation-agnostic specification of the URL pattern that other libraries, like path-to-regexp
could adhere to. I imagine once URLPattern
lands in browsers, there won't be any way to validate your custom implementation is compatible with it, which is quite a nuisance.
I don't mean to be intrusive, but would you perhaps like to collaborate on the URL pattern specification with me? Give that this is an actual API coming in browsers, we can base its behavior on the suggested verbal specification from the Chrome team. I can reach out to them and suggest collaborating on the spec as well.
While it feels like a detour to write down a specification in an abstract format like Gherkin, I think it can benefit the ecosystem, as such feature files can be turned into automated tests given only implementation-specific steps to cover the specification's vocabulary—something a conventional verbal specification cannot accomplish.
I've reached out to one of the W3C members to offer my help with the URLPattern
. These are some great news!
Hey. Thank you for an awesome library!
I'd like to adopt this library as the request URL matcher for Mock Service Worker, but the lack of absolute URL support prevents me from doing so.
Please, would you consider supporting absolute URLs?
Current behavior
Suggested solution
The support for this should be rather straightforward: tell the parser to expect a double slash (
//
) after the parameter name token (:
) as a valid next character.I'd be happy to submit the pull request if you find this support in line with the vision for the library.
Alternatives