[danshome]

Fixes #55. Refs #56 (group-name errors only).

What this fixes

strToChars decodes escapes before the tokenizer runs, so an escaped character could be read as group syntax. JavaScript rejects all of these, but ret accepted them, and reconstruct turned them into different, valid regular expressions:

Pattern	JavaScript	ret before	ret after
(?\u0021a), (?\x3Da), (?\x3Aa), (?\x3Cn>a)	SyntaxError	accepted as (?!a), (?=a), (?:a), (?<n>a)	Invalid group at column 2
(?<n\x3Ea)	SyntaxError	group n, closed at the escaped >	Unclosed capture group name
(?<\x61>a), (?<a\x62>c)	SyntaxError	groups a, ab	Invalid / Unclosed capture group name

The four lowercase examples in #55 ((?\u003aa) etc.) are rejected before and after this change, but only because ret does not decode lowercase hex yet; with this check in place they stay rejected once it does.

How

• The character after (? must be literal in the source. This is the same check the modifier parser from feat: modifier support #50 already makes, now one isLiteral helper that both use. Errors use the existing modifierErr, so they report the column in the original source.
• A \ straight after (? is never group syntax, which also covers escapes that decode to an escaped special character ((?\x28a) becomes (?\(a internally).
• Group names follow the specification: a name character may be literal or a \u escape that is still a valid name character ((?<\u0061>a) is the group a), but not \x, \c or other escapes.
• The closing > may be literal or \u003E. The specification requires a literal > here, but V8 (Chrome, Node) and JavaScriptCore (Safari) both accept (?<n\u003Ea) as the group n, and SpiderMonkey uses V8's regexp parser, so ret follows the engines. \x3E is rejected, as it is by all of them. Happy to switch to the strict spec behaviour if you prefer.
• Group-name errors now report the source column and the character as written, so an earlier escape no longer shifts them (\x61(?<1a>b) reports column 8, not 5). Patterns without escapes get exactly the same messages as before.

Relation to #51

#51 removes the up-front decoding, which fixes the (? part of this by design. This is a small fix in the meantime; if #51 lands first, that part can simply be dropped. The group-name rules and the tests still apply: as currently written, #51 rejects valid \u names such as (?<\u0061>a), and these tests would catch that.

Not changed (pre-existing)

• \u{...} escapes in names (valid JavaScript; ret does not decode \u{...})
• Non-ASCII group names (captureGroupChars is ASCII only)
• (?<\u0024>a): $ is valid, but the decoder re-escapes it as \$
• Lowercase hex such as \x3d is not decoded (Clarify supported JavaScript regex syntax in the README #57); I have a follow-up PR ready that builds on this one
• "Invalid group" errors count columns from 0 and name errors from 1; I kept each as it was

Testing

• New tests in test/error-test.ts and test/main-test.ts; the error tests fail without the change.
• 364 passing; tsc, eslint and coverage (100%) clean; CI green on Node 20, 22 and 24 on my fork.
• Independent of my lookbehind PR (feat: add lookbehind support #59): the two merge cleanly in either order, and all tests pass on the combination (387).

[fent]

Hello, thanks for your contribution!

• The closing > may be literal or \u003E. The specification requires a literal > here, but V8 (Chrome, Node) and JavaScriptCore (Safari) both accept (?<n\u003Ea) as the group n, and SpiderMonkey uses V8's regexp parser, so ret follows the engines. \x3E is rejected, as it is by all of them. Happy to switch to the strict spec behaviour if you prefer.

This is the strangest quirk for me, and I agree with the decision made here, following the engine makes sense.

Anyway, lgtm!

[github-actions]

🎉 This PR is included in version 0.6.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀