Readable Regular Expressions for JavaScript/TypeScript, Inspired by Emacs' rx

i really like this kind of type-checked and very clear regex engineering in theory, but in practice i find little use for them for a couple of reasons:

• my regexes tend to be fairly simple, a lot of my regexes are just list of words or extractors which boil down to something like seq(someBeginToken, capture(oneOrMore(not(someEndToken))), someEndToken) or just a match against a fairly legible log line with one or more capturing groups like Invalid user .* from ([0-9.]+) port .*. to someone who frequently reads/writes regex the direct regex syntax will likely be easier to understand, since it is more terse and the regex is more closely aligned with what one is actually parsing.
• if a regex is more complex then that is usually not the case because the syntax is difficult to parse, but because of the underlying FSM has a lot of complicated structure which is not made easier to understand through the different nicer syntax but through better formatting / comments / naming of sections, which is achieved more easily with either adjacent or inline comments (by using just string concatenation and the comments of the ambient language, or by using a built-in comment feature, such as java.util.Pattern.COMMENT)
• regexes themselves tend to be a bit of a universal meta language that everyone ends up mostly understanding. if i see a regex, i know that .* just means "basically anything and however much of it", and so will everyone else i am working with. custom abstraction layers on top are often a new concept and introduce their own idiosyncrasies. sharing normal regexes (as long as they dont use too many weird regex extensions) between projects is also a lot easier.

i still like things like this, but because of those associated costs i never end up using them in any real projects

It's way nicer but also if you've made an API that looks like this, I think you may as well go a little further and make it create parser combinators like Parsec's style or LL(1-or-more) parsers because they tend to be very readable too for exactly the same reason..