encode option for compiled paths throw an error

[ryansukale]

See attached screenshot as taken from Runkit in NPM.
That example is copied directly from the Readme.

[blakeembrey]

@ryansukale I'm not sure I follow, this seems like a valid error. You're creating a path that would not be matched by the path (e.g. the path does not match the expected input). What do you expect should happen?

[blakeembrey]

You're right that the README seems wrong though! That's my mistake 😄

[3den]

@blakeembrey is there anyway you can allow a decoded param to be injected? e.g.

const path = compile('/my/:anything');
path({anything: 'something/weird&decoded'}, {encode: (v) => v});
// should return => /my/something/weird&encoded

[blakeembrey]

@3den I could relax this, but I'd like to understand before I just into breaking anything. It should be noted that, given that returned string parsed with path-to-regexp again, it will not match. That's what the error is trying to avoid - building a path that wouldn't match. What you can do, if you explicitly want slashes, is a custom regexp or repeated params (e.g. /:anything(.*) or /:anything+).

[ellioseven]

@blakeembrey I am having difficultly trying to apply what @3den is attempting.

As an example I want to do something like this:

const toPath = pathToRegexp.compile("/content/:path");
const p = toPath({ path: "foo/bar/baz" });
console.log(p);
// actual: /content/foo%2Fbar%2Fbaz
// want: /content/foo/bar/baz

However the value always seems to be encoded, and as far as I can see, there is no opt-out option?

[blakeembrey]

@ellioseven He overrode the encode option in his example above. However, you should really just be doing /:path+ and pass an array value.

[paulmelnikow]

I have the same use case @ellioseven mentioned: badges/shields#2649.

As you suggested, pathToRegexp.compile({ content: 'foo', path: ['bar', 'baz'] }) produces the value I'd like, whereas pathToRegexp.compile({ content: 'foo', path: 'bar/baz' }) encodes the slash.

Since pathToRegexp('/:content/:path+').exec('/foo/bar/baz') produces ["/foo/bar/baz", "foo", "bar/baz"] it's a bit unexpected that I can't feed the '/bar/baz' value back into pathToRegexp.compile('/:content/:path+'). There may be a reason this isn't possible, though my expectation is that these operations would be symmetric.

When I'm using a literal, it's possible to use an array, though another spot where I'd like to use this is on user input:

Converting the path to an array of components would be possible, but a bit tricky. Currently I'm working around this by concatenating the strings myself (instead of using compile).

[blakeembrey]

@paulmelnikow I think your example is more reasonable since that is producing a valid path. The example above from @ellioseven and @3den didn't use a repeated path so the slash would be invalid if it were to be matched again. One thing I'm wary of doing is mixing decoded and encoded values as input params. Another thought is that the input function of a repeated param could split a string input explicitly, then run encode over the results. In this case, something like foo:bar/bar:baz would properly encode the colons and keep the slash as valid. If you wanted to explicitly define the params and encode path characters you'd pass an array such as ['foo:bar', 'bar:baz']. Does this sound reasonable?

Alternatively, I can expose a better matching function and start moving away from regexp.exec as an interface. It's honestly not a perfect interface since I also end up building the same sort of matching into my end applications, e.g. https://github.com/blakeembrey/react-route or https://github.com/serviejs/servie-route. Standardizing the match function would enable replacement of any other path matching function too, e.g. a custom function.

[paulmelnikow]

Oh, man, I'd love to provide helpful feedback, but since my perspective on this from higher in the stratosphere, I'm a teeny bit lost! 😝

One thing I'm wary of doing is mixing decoded and encoded values as input params.

It seems to me the inputs to pathToRegexp.compile('/:path+').(...) should always be unencoded, with the expectation that the function will encode them. 👍

Another thought is that the input function of a repeated param could split a string input explicitly, then run encode over the results. In this case, something like foo:bar/bar:baz would properly encode the colons and keep the slash as valid.

I think what you're saying is that pathToRegexp.compile('/:path+').({ path: 'foo:bar/bar:baz' }) would be '/foo%3Abar/bar%3Abaz'. 👍

If you wanted to explicitly define the params and encode path characters you'd pass an array such as ['foo:bar', 'bar:baz'].

That I'm not following.

[blakeembrey]

The final point just means that the repeated parameters expects an array input. If you give it the array, it'll encode each parameter and join them by the delimiter automatically. It currently produces the same result as the proposed workaround for when you give it a single string.

Reference:

path-to-regexp/index.js

Line 163 in 4eee1e1

for (var j = 0; j < value.length; j++) {