Patterns with capturing group(s) spanning over "/" are not compilable about path-to-regexp HOT 12 CLOSED

Thanks for the report. I'll correct this today. I think the correct behaviour is to flag this in the parsed tokens, then re-use the flag when compiling to append it raw.

from path-to-regexp.

By the way, you can use an array for the asterisk feature.

Edit: Ignore me, was being dumb. No, you can't.

from path-to-regexp.

If you mean like this:
/assets/:path+
than unfortunatelly I can't, because I use pathToRegexp delivered with Express 4 for url matching and I use the new version only for pattern to url translation (compilation).
Also in my use case, string is a little bit more practical, because I use the "a/b/c/d" part as an asset identificator, so I would have to parse it first: assets.getUrl("a/b/c/d")

from path-to-regexp.

I am not sure if you've actually fixed the issue. It's not just asterisk ... this issue is applicable to any match which spans over "/" characters and is not repeatable, like:
/assets/(.*)
Does it cover such cases?

from path-to-regexp.

No, that's intentional. It's impossible to work with that unless we analyze RegExps - which won't be happening.

E.g. (.*) is trivial. What about [^\/]*? What about other negations? How should that work? Should we try and analyze the RegExp character by character and escape in the reverse? I don't think it's worth it, honestly. If there's a simple proposal, you're welcome to open an issue and it could be implemented.

from path-to-regexp.

Well woudn't be than better, in case of string patterns, to disallow matching over path separators unless it's explicitely stated by * or + modifiers?
So the regex pattern itself would be always applied on each path part isolated from others.
Than it would be clear that params spanning over "/" always end up as an array and you also know which ones - the ones with multiplicity modifiers.

from path-to-regexp.

How would you stop people from putting / in their regexp string? By erroring?

Edit: Also, I'm not sure in general. I don't have clear data on whether anyone actually uses the RegExp feature to span multiple segments (other than the obvious "match all") but I'm sure someone is. This would be a change for 2.0 either way.

from path-to-regexp.

No... the doc states this (in BC breaks):
No longer a direct conversion to a RegExp with sugar on top - it's a path matcher with named and unnamed matching groups
What I propose is to change the matching logic in a way, that instead of matching agains a single generated regex, to actually match agains multiple regexes (when it's necessary) single path part at a time.
So even though the regex would contain "/", it would be matched only agains a single path part isolated from others. The multiplicity modifier would just instruct the matcher to try to match the same pattern against following parts.

To me the pattern to path conversion is a neccessity and I much appreciate this feature.
However if there is such functionallity I think it's neccessary to make clear when the pattern is convertible to path.
The documentation states it works with string patterns, well thats obviously not true, only subset of them is really convertible.
So I propose to desing string patterns and string pattern matcher in a way that any string pattern is convertible back to path, while maintaining path matching as flexibile as possible.
For cases when this is not possible and super flexibility is needed (I don't believe there would be many of them) one can still fallback to non-compilable regulars, while loosing the pattern to path conversion functionality of course.

from path-to-regexp.

I didn't understand some of what you wrote, but I think I got the gist. I'm not arguing against the change, you don't need to quote things I wrote. I know what was meant when I wrote it. Maybe what I wrote doesn't translate to what you expect?

Either way, what you're proposing is a major breaking change. Even bigger, it should be a new library. I don't think I can effectively do path matching using a regexp anymore if it's evaluated segment by segment. That's not a problem, just not meant for this library.

Edit: To be clear, I like the idea. I just can't implement it here.

from path-to-regexp.

When I got the idea I realized it would require quite different matching mechanism than converting a pattern to single regex, which somehow does not collerate with project name "path-to-regex".
But than I also realized that it might not be such a problem as the quoted statement somehow implies that pattern to (single) regex conversion might no longer be the crucial goal of the project.
To make clear that my idea is based on that assumption and to indicate that I am aware that it might be againts the current project philosophy or implementation, I quoted it.
Nothing more in it, I apologize for any inconvenience.

I actually proposed that only as an idea or something to think about. I didn't assume it would be actually implemented, at least not in current major version.

You say you like the idea. Do you believe it should be part of the reference routing machanism of express?
Because if you do, than I believe it should be part of this project, because it's already adopted by express.
And if you don't, well than maybe it's not such a good idea I think.
(just for clarification - the idea is that all string patterns should be convertible back to path)

from path-to-regexp.

That's fair. The issue with that implementation living here is that, as you mentioned, it would no longer be going to a regexp for matching. For Express 5.x, I want to make pluggable routers/path matching more prominent so maybe it's a candidate for that? The reason for the other comment was that Path-To-RegExp 0.x would literally allow RegExp-like things without them being in a matching group - I can reword that to make more sense in context, most people probably never used their path string as a plain regexp.

from path-to-regexp.

Maybe there could be an option to not escape "/"? It would probably have to be per param option, so am not sure where to place it. Maybe something like this?

toPath({ 0: { value: "a/b/c/d",  escPathSeparator: false } })

Also maybe that option could replace the "asterisk" token indicator so something like this would be possible:

var tokens = pathToRegexp.parse('/route/(.*)'); // or any other regex
tokens[1].escPathSeparator = false;
var toPath = pathToRegexp.tokensToFunction(tokens);
toPath({ 0: "a/b/c/d" }); // no need to pass any options

It actually works even now by setting tokens[1].asterisk = true; but it doesn't make much sense

Actually why not to allow to everride any token's option in toPath function?

toPath({ 0: { value: ["a","b","c","d"], repeat: true } });

This actually works already as well, if done with tokens:

var tokens = pathToRegexp.parse('/route/(.*)'); // or any other regex
tokens[1].repeat = true;
var toPath = pathToRegexp.tokensToFunction(tokens);
toPath({ 0: ["a","b","c","d"] });

EDIT:
As I think about it, it would be nice, if express router could accept tokens (in a form of some Route object) aside from plain strings/regexes.
The Route object can contain arbitrary information inexpressible by string patterns, like "strict" or "end" options.
They are also more resiliant to changes - features could be added even though they wouldn't be supported by (current) pattern syntax. Or when the pattern syntax is changed, the route objects might still work the same way.

from path-to-regexp.