If ok I'll apply util to the modules mentioned by #7549 😊

I think it is ok to have this refactoring in a single PR, yes. I like that the regexes were combined in a single one. About the utils, maybe CleanString shouldn't extend String? Now you have the string itself, raw and clean. I think I would find it less confusing to use a simpler type { raw: string, clear: string } or something like this, and regular free functions to pass it around.

@patak-dev how about this. I think findEmptyStringRawIndex also can handle in walkCleanString. I don't know if it should continue to encapsulate like this.

if(s[0] === '`' || s[0] === '"' || s[0] === "'") {
 const [start, end] = findEmptyStringRawIndex(cleanString, s, index)
 match[xxx] = cleanString.raw.slice(start, end)
}

I think it is ok to have this refactoring in a single PR

If need a new PR, I think should merge this PR first. 👀 #7549 dependence on CleanString

But there is a known bug that has not been resolved that the nested string template syntax does not match. Since the previous regexp match should just ignore the comment, adding a string template might have a destructive error, since most of the time all the code is processed.

maybe string template don't need to replace all. #7647
just need to

const str = `${a${`c${`d`}`}b}`

const clean = `${\0${`\0${`\0`}`}\0}`

Because regular expressions can't be written, we can only use lex methods such as import.meta.glob. If this method is acceptable, even handle string and comment in lex 🙆‍♂️

@poyoho interesting. Using a lexer only for template strings may be fast enough 🤔
What do you think about separating this into two PRs though? I think we could merge the cleanup and fix for comments and strings if we get others to review. And then we can keep discussing about the new template string lexer in another PR to avoid blocking this one.

Note: if you think it is hard to divide it in two, then let's keep it together and ask for others to check it out.

It's okay, it's easy