mswjs/node-match-path

Matches a URL against a path. Parameters, wildcards, RegExp.

node-match-path's Issues

Does not work with urls that have a request content type extension and parameters

I haven't tested this extensively, but I'm using this library via MSW and I think I've found a fairly common use case that is not supported. Specifically, this library will not handle a url like
/api/books/:bookId.json.

In manually inspecting this file https://github.com/mswjs/node-match-path/blob/master/src/pathToRegExp.ts, I believe the problem is that line 19 does not include a "." in the list of characters to terminate the parameter match.

I'll try to submit a pull request and appropriate tests in the next day or so, but figured I'd go ahead and report the issue.

Consider "jest.each" or "jest-in-case" for repetitive test scenarios

Current behavior

Currently the library uses its own abstraction to provide similar test assertions for different input data.

Expected behavior

Consider jest.each or jest-in-case instead.

"user/:userId/*" does not match "/user/abc/messages"

Expected behavior

Given user/:userId/* path it must match the url: /user/abc/messages.

Consider replacing named capture groups in RegExp

Why

• mswjs/msw#223

Named capture groups are not currently supported in the latest release of Firefox (77). They will never be supported in IE. They have no support in Firefox for Android.

Escape question marks ("?")

Current behavior

Question marks in the string path are returned as-is, creating a logical RegExp operator.

Expected behavior

Question marks in the string path are escaped: \?.

CI: What about migrating to GitHub Actions for consistency with the rest of the repositories?

Trailing path parameter matches query parameters

Steps to reproduce

match('/user/:userId', '/user/abc-123?hello=true')

Current behavior

{ params: { userId: 'abc-123?hello=true' } }

Expected behavior

{ params: { userId: 'abc-123' } }

Query parameter must be disregarded during path parameter match.

Underscore in parameter name is forbidden

• Originates from mswjs/msw#392

Currently the RegExp for path parameter names does not account for the underscore character "_". This produces falsely negative path matches for paths that include parameters that contain underscores.

Current behavior

match('/user/:user_id', '/user/1')
// no match

Expected behavior

match('/user/:user_id', 'user/1')
// { matches: true, params: { user_id: 1 } }

Patch matching is case-sensitive

Current behavior

Expected: /foo
Actual: /Foo

Result: no match.

Expected behavior

Should behave as ExpressJS path matching in terms of case-sensitivity.

Expected: /foo
Actual: /Foo
Actual: /foo

Result: matches.

Support optional parameter notation

Expected result

const path = '/image/:transforms?/:version?/:id'

match(path, '/image/a,b,c/1.2.3/id') // { params: { transforms: 'a,b,c', version: '1.2.3', id: 'id' } }
match(path, '/image/a,b,c/id') // { params: { transforms: 'a,b,c', version: null, id: 'id' } }
match(path, '/image/id') // { params: { transforms: null, version: null, id: 'id' } }

Reproduce this behavior in the Express Route Tester.

Wildcard expects at least one character

Current behavior

/user/details*

Matches: /user/details0
Doesn't match: /user/details

Expected behavior

Matches: /user/details and /user/details0

This is the behavior exhibited by ExpressJS, we should respect that.

Path matching is sensitive to trailing slash

Consider this usage example:

import { match } from 'node-match-path'

match('https://test.msw.io', 'https://test.msw.io/')

Current behavior

The given path won't match the expected path.

Expected behavior

Trailing slash is ignored when matching paths.

Motivation

Trailing slash is often appended by the client automatically. For example, executing fetch('https://test.msw.io') would perform an actual request to https://test.msw.io/.

Support RegExp as "path" argument

I think the library should support RegExp supplied as the path argument in order to be compatible with path-to-regexp. Since the given string path is converted to a RegExp, handling an explicit RegExp won't be a big problem.

Cannot have a path parameter with length 1

/user/:u

Does not create a u parameter at all. Maybe be an issue in how RegExp is constructed.