Better regex

[Palloxin]

Better regex

[greptile-apps]

Greptile Summary

This PR refactors regex patterns across 15 files, making greedy quantifiers lazy (.* → .*?, [^]* → [^]*?), replacing [\s\S] with the equivalent [^], and restructuring several lookbehind assertions without changing their semantics.

• Greedy → lazy quantifiers: Most changes (modelist, clientManager, runtimeProviders, dev.js, setup.js) swap greedy quantifiers for lazy ones in anchored patterns where both give identical results; the getConstructorRegex change in hooks/modify-java-files.js is a genuine correctness fix that prevents \\(.*\\) from spanning multiple method declarations.
• [\\s\\S] → [^]: Pure equivalence refactor across renderer.js, after_install.js, before_uninstall.js, and sftp.js; [^] and [\\s\\S] both match any character including newlines in JavaScript.
• Lookbehind restructuring: The editorFile.js, changelog.js, console.js, and rspack.config.js changes restructure the position of the lookbehind assertion while preserving the same semantic meaning.

Confidence Score: 5/5

Safe to merge — all regex changes are either semantically equivalent refactors or genuine correctness improvements.

Every change was verified against multiple input scenarios. The greedy-to-lazy switches in anchored patterns produce identical matches. The [\s\S] to [^] substitutions are identically equivalent in JavaScript. The lookbehind restructurings in editorFile.js, changelog.js, console.js, and rspack.config.js all preserve the original intent. The lazy fix inside the constructor parameter-list pattern in modify-java-files.js tightens correctness by preventing the pattern from spanning multiple method signatures.

No files require special attention.

Important Files Changed

Filename	Overview
hooks/modify-java-files.js	Lazy quantifiers added to getConstructorRegex, getInterfaceDeclarationRegex, and getClassDeclarationRegex; the .*? in the parameter-list part is a genuine fix preventing the pattern from spanning multiple method declarations.
rspack.config.js	Lookbehind restructured from (?<!.m).(sa
src/cm/lsp/clientManager.ts	[\w+-.]*? made lazy before the terminal colon — greedy and lazy produce identical captures for URI scheme matching.
src/cm/modelist.ts	Extension pattern prefix changed from ^.* to ^.*?; with ^ and $ anchors, lazy and greedy give the same match result for all file extension checks.
src/lib/editorFile.js	Lookbehind moved from /(?<!\r)\n/ to /\n(?<!\r\n)/; correctly avoids converting \n that follows \r, fixing the Windows line-ending conversion logic.
src/lib/console.js	matchRegex rewritten from (?<!%)%[oOsdifc] to %(?<!%%)[oOsdifc] (equivalent); <(.)> tightened to <([^>])> (improvement); (.+) made lazy in stack-trace parser.
src/pages/markdownPreview/renderer.js	[\s\S]+ and [\s\S]* replaced with [^]+ and [^]* in math block patterns — purely equivalent in JavaScript.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Regex Changes in PR] --> B[Greedy to Lazy quantifiers]
    A --> C[Character class equivalence]
    A --> D[Lookbehind restructuring]
    B --> B1[".*  to  .*? in anchored patterns"]
    B --> B2["Genuine fix in getConstructorRegex"]
    C --> C1["[\\s\\S] to [^] - Equivalent in JavaScript"]
    D --> D1["Fixes Windows line-ending conversion in editorFile.js"]
    D --> D2["Equivalent semantics in changelog, console, rspack"]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Regex Changes in PR] --> B[Greedy to Lazy quantifiers]
    A --> C[Character class equivalence]
    A --> D[Lookbehind restructuring]
    B --> B1[".*  to  .*? in anchored patterns"]
    B --> B2["Genuine fix in getConstructorRegex"]
    C --> C1["[\\s\\S] to [^] - Equivalent in JavaScript"]
    D --> D1["Fixes Windows line-ending conversion in editorFile.js"]
    D --> D2["Equivalent semantics in changelog, console, rspack"]

Loading

_{Reviews (2): Last reviewed commit: "Update editorFile.js" | Re-trigger Greptile}

[Palloxin]

Fixed the problem the... summary pointed out.

[Palloxin]

however, I cannot garantee they are 100% better or not-breakers without string contexts. For example /aa.*:/g might aim to match ONLY the very last : of the string.

If you have these regexes:

1. /aa.*:/
2. /aa.*?:/

and this string:
aaaaa:bbbb:cccc:

The first one(1) will match aaaaa:bbbb:cccc:

The second one(2) will match only
aaaaa:

The advantage of the lazyfication is that it prevents backtracking.
/.+:/ =>([^\n]+:) eats everything until end string, then it backtracks(one step at time behind), checking if : is present (in front) at each step. It is a bigger waste of time the longer the string, and using .+?: is faster, unless you need the very last : of the string.

ANOTHER case where .+ is better is when if you have a 100 meter long string, and you know(100%) the : you want is in the last 5-10 meters range, /.+:/ is faster https://jsbench.me/ggmesp8ybc

[RohitKushvaha01]

@greptileai