Fix ArkRegex quantifier issue

[codpro2005]

Fixed ArkRegex quantifier issues (#1531, #1534)

[codpro2005]

To reduce ternary nesting here (and slightly improve scalability):

r["min"] extends never ? null
: r["max"] extends never ? null
: r

I was considering adding a someExtends<ts, t> generic utility type so it could be used like this:

someExtends<[r["min"], r["max"]], never> extends true
? null
: r

But I'm unsure whether this is worth it.

[ssalbdivad]

Hey thanks for submitting this! Would love to see these scenarios handled better and appreciate the detail mirroring the behavior of new RegExp 1:1 here, but we actually have the luxury of failing for cases like this that are almost certainly a mistake.

Can we adjust the handling here so that for invalid quantifiers, we write a descriptive error like Quantifier ${actual} must be a natural number?

We should be able to use the existing parseInteger type to determine this or tryParseInteger which has a builtin parameter for an error message. We could potentially prompt the user to use an escape char for the opening { if they really do want the literal string, although I think that will be quite rare and I don't want the message to be too verbose so up to you.

[codpro2005]

That makes sense to me, I'm not a huge fan of the implicit literal treatment for invalid quantifiers for native RegExp anyways. I too agree that the escaping hint may be avoided since it's an edge case and probably intuitive enough that it doesn't need to be mentioned if you did need it.

It's worth noting that in the test cases falls back to literal on empty and falls back to literal for non-numeric quantifiers are treated as literals too so maybe it could be considered to always request escaping the { when quantifiers aren't desired? Not sure though.

I'll try to get to it in the weekends. If I'll have any questions or notes I'll let you know. Thanks for the review!

[codpro2005]

I fixed it, some things I was uncertain about:

• Should the quantifier variable in the error message be the full quantifier (e.g., {-3,4}) or just the invalid number (e.g., -3)? I went for the first, which is why I adjusted the error message to Quantifier ${quantifier} must use natural numbers.
• I'm assuming it's appropriate to show an error message on leading zeroes since there's no reason to keep them in quantifiers. If so:
  • Should I use the same error message for leading zeroes, or prefer something specific like Quantifier ${quantifier} should avoid leading zeroes?
• Should the error be singular/plural based on quantifier form?
  • {n} | {n,} => Quantifier ${quantifier} must use a natural number
  • {n,m} => Quantifier ${quantifier} must use natural numbers

Edit: Looks like a step failed, that's not my strong suit so I'll give this a look on another day.

[ssalbdivad]

Wow this is perfect I love it- great work 💯

The CI failure is just due to some recent issue in node 25 so I'm going to merge this as is and will publish in the next few days. Thanks again!

[codpro2005]

Thanks a lot, David! Learned a lot working on this, so it's great to be able to contribute back 🙌