How to safely access the regular expression compiled from a path?

[mxxk]

@blakeembrey with the removal of the re property in fb4d11d#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80L483-L485, how can the regular expression be safely accessed by the consumers of path-to-regexp?

Motivation

In my case, I'm working around the removal of support for string[] in v7 as mentioned in #310 (comment), so I'm looking for a stable way to get the regular expression.

I see that with fb4d11d, the redos.ts script (which relies on the ability to get the regular expression) performs an as any cast to work around the re property removal from the type signature:

-const { re } = match(path);
+const { re } = match(path) as any;

I could do the same, but it doesn't seem safe to rely on an undocumented property from outside of path-to-regexp.

I'm curious to hear your recommendation @blakeembrey 🙂

Note

P.S. Thank you for maintaining this repository.

[blakeembrey]

Do you need the regular expression or do you want string[] support added back? I think both can be done. Regexp output support was removed in an attempt to allow me to rewrite the library without regular expressions, but that might be a lost cause and makes the package a misnomer.

[mxxk]

Regexp output support was removed in an attempt to allow me to rewrite the library without regular expressions but that might be a lost cause and makes the package a misnomer.

Ah I see, that makes sense. Haha yes I also thought of the package name being a misnomer if it's no longer possible to get the regular expression. 😄

Do you need the regular expression or do you want string[] support added back? I think both can be done.

Well, the use case I had in mind relies on string[], but I recognize that it may be uncommon and was probably removed from path-to-regexp for good reason.

When I created this issue, I thought it made more sense to expose the regular expression, but I see your point that the same underlying ask can also be resolved by restoring support for string[]. Thank you for laying out these options. Either approach would work here and in #310 (comment).

Zooming out, exposing the regular expression is the more general option of the two, and if I had to guess, it may also serve other less common use cases of this library.

[blakeembrey]

Both have been added back. I guess we'll wait another potential major if I happen to revisit and rewrite into a non-regex output 😄

[blakeembrey]

The main reasons it is removed and less recommended to use:

1. Decoding works automatically using match (reduce user error).
2. The hope I'd have time to revisit using a regex to match altogether.

But I understand some people might just want to regexp.test or something, and if I don't have time to rewrite exposing it again is less of an issue.

[mxxk]

Thank you @blakeembrey!