Graham Sutherland / Polynomialprotip: ALWAYS use regular expression literals in JavaScript and TypeScript and any other language that supports it, instead of writing your regex out in a string. I cannot count how many critical security bugs I have found over the years from someone writing a regex like "^en\.wikipedia\.org$", which is incorrect because the \. is treated as *string* escape sequence (an invalid one that just produces .) which then results in the regex being "^en.wikipedia.org$" which matches "enowikipedia.org".
this doesn't just come up in domain name allowlisting, it's eeeeverrryyywhere. the double escapes ALWAYS catch people out. use the regex literals, they'll save your ass. and if your language or toolchain or linter has a strict mode that can yell at you about bogus escape sequences in strings (or in regex literals too, for that matter) then turn it on and turn it up to 11.
imo languages should default to making invalid string escape sequences a compile error. so please go yell at (by which I mean "politely but firmly ask") your neighbourhood language standards committee to be strict on this. by default. so I don't keep finding this bug class for another 15 years.
also if you are unfortunate enough to have to PR slop code then this is a ridiculously common failure mode in LLM output and one you should look out for. the model can't reliably converge on tokens that are applicable to the context of a regex inside a string within the specific language, and instead tends to regress back to plain regex syntax or weird inconstent mixtures of string/regex escape sequences.
C# doesn't support regex literals, but it does at least throw a compilation error on invalid escape sequences in strings, and throws an exception if a regular expression contains an invalid sequence.
also both Visual Studio and VSCode have really solid syntax highlighting for regular expression strings, both of which can infer that the string is intended to be a regex by identifying the StringSyntax attribute on a method parameter. plus it has build-time compiled regexes.
Pxl Phile@gsuberland same with Golang.
But there are some catches with different string literal types. Either way, it is a runtime error during the regex compilation OR a fundamentally wrongly formulated regex 😂 but not an invalid escape.