query parameters and RegExp's involving path parameter

[evanyeatts]

I encountered an inconsistency when constructing RegExp's for paths involving path parameters. Here is an example:

var matcher = pathToRegexp('/fetch');   // /^\/fetch(?:\/(?=$))?$/i
var a = '/fetch';
var b = '/fetch/';
var c = '/fetch?foo=bar';
var d = '/fetch/?foo=bar';

Strings a and b match against the regex, and both c and d do not. This matches my expectation that pathToRegexp is not meant to manage query parameter parsing without additional code.

var matcher = pathToRegexp('/fetch/:id');   // /^\/fetch\/((?:[^\/]+?))(?:\/(?=$))?$/i
var a = '/fetch/1';
var b = '/fetch/1/';
var c = '/fetch/1?foo=bar';
var d = '/fetch/1/?foo=bar';

Strings a, b, and c will all match against the regex, but d will not. I would expect c and d to both fail to match given the behavior in the previous example. The trailing / makes the difference: regexp visualization. The capture group intended to match the path param ends up also matching against the query with string c.

Is the issue here just that pathToRegexp is not designed to analyze request url's that have not had their query portion removed? Should I clean the query first?

[blakeembrey]

Yes, you should remove the query first. This only handles pathnames, not the query portion, as that would be a mess to correct route on 😄

[dougwilson]

Probably add a note to the README to mention that the returned regular expression is meant to be matched against the pathname