trailing capture about path-to-regexp HOT 12 CLOSED

@jonathanong How about adding support for various regexp-style modifiers (+ for more than one part, * for zero or more and ? for optional)? The plus style sounds like what you're after here.

from path-to-regexp.

oh that makes sense. i think of * as just "anything, i don't care" not a regexp wildcard when defining routes though.

from path-to-regexp.

In my refactor I removed the ability to use an asterisk like that in favour of just using a regexp - (.*) - since that was what it did anyway internally.

from path-to-regexp.

Anyway, if you're on board with it - I can add the ability tonight and get everything tested.

from path-to-regexp.

i thought (.*) just checked the current fragment. i'd like file to be something like lib/index.js or something.

from path-to-regexp.

Well, * was always replaced with (.*) - there was never any understanding of fragments. If you wanted file to match that, you could use /:file(.+) or with this change /:file+.

from path-to-regexp.

ohhhh this changes everything!

from path-to-regexp.

Haha, is that good or bad?

from path-to-regexp.

good. if that's the case, we might as well remove * support outside of regexps. it doesn't add much, and (.*) is much more explicit. didn't realize that. not sure how many conversations i confused you with this.

from path-to-regexp.

Awesome! Don't worry about it, at least we got to it eventually. I'll implement this tonight, add some more test cases and documentation and we should be ready to go. Then, I'll look at adding the feature the guy was after in path-match and the changes will cascade through.

from path-to-regexp.

@jonathanong https://github.com/component/path-to-regexp/pull/28 - just need to update the keys array later with the syntax to denote these matches.

from path-to-regexp.

Supported using + param suffix.

from path-to-regexp.