Strip comments from the .js files under a directory, in place.

This used to be three regexes, and the module said so: "Naive RegEx approach – may fail for comments in string literals". It did fail. A file containing

trimmed.startsWith('//')

was published with the //') eaten and the rest of the line gone, because // inside a string is indistinguishable from // starting a comment unless you know whether you are inside a string — which is to say, unless you lex. Callers worked around it by excluding whole directories from stripping (vendored three.js, for one), which is a big hammer for a problem that only ever needed the scanner below.

So: a single pass that tracks what it is inside — code, a string, a template literal (including ${...} interpolation, which returns to code and can nest), a regex literal, a line comment, a block comment — and only removes a comment when it is actually in one.

The one genuine ambiguity

A / in code starts either a regex literal or a division, and telling them apart needs the grammar, not the characters. The standard heuristic is used here: a / begins a regex when the last significant token was an operator, an opening bracket, a statement separator, or a keyword that can be followed by an expression (return /^a$/.test(x) is real code in the wild) — and is division when it followed an identifier, a number, or a closing )/]/}.

} is deliberately in the division group. Both readings can be wrong, but they are not equally wrong: mistaking a division for a regex swallows everything up to the next /, while mistaking a regex for a division just scans the regex body as code, which removes nothing and changes nothing unless that body happens to contain a quote or a comment marker. The cheap mistake is the one worth making.