perf(linter/typescript/no-require-imports): compile allow patterns once

[connorshea]

match_argument_value_with_regex recompiled every allow pattern with Regex::new for each require() call and TSImportEqualsDeclaration it checked. This compiles the patterns once in from_configuration into a serde/schemars-skipped Vec<Regex> on the config and matches against that. Same shape as #24412 and #24413.

Benchmark

Fixture: a generated requires.ts with 30,000 one-line require calls of the form

const lib12345 = require('./lib12345');

None of the paths match an allow pattern, so every call pays the full allow-matching path and reports on both binaries (the common case for this rule: mostly-disallowed requires with a small allowlist). The allow/skip path itself was parity-checked separately with a canary mixing allowed string literals, an allowed template literal, an allowed import ... = require(...), and reported requires.

Config: single-rule .oxlintrc.json so nothing else contributes to the timing:

{
  "plugins": ["typescript"],
  "categories": { "correctness": "off" },
  "rules": { "typescript/no-require-imports": ["warn", { "allow": ["/package\\.json$", "^some-package$", "\\.jsonc$"] }] }
}

Method: two release binaries (baseline from main, this branch), run interleaved in alternating order for 40 paired samples with warmup, timed with time.monotonic_ns(). A parse-only config on the same fixture showed no meaningful difference between the binaries (1.018×, t=1.7), so the delta is attributable to the rule rather than binary-layout noise.

	mean
before	410.80 ms
after	32.26 ms

12.7× faster (paired t=229, 40/40 wins). The magnitude scales with require-call count × number of allow patterns; configs that don't set allow are unaffected (the matching path is already guarded by allow.is_empty()). Diagnostics output is identical between the two binaries on the fixture (30,000 diagnostics) and the canary.

It is very unlikely that this will have much of an impact in most cases, as the option is rare and so are require() calls these days. But it's a simple enough improvement.

Behavior note

An invalid allow pattern previously panicked (.unwrap()) at the first require() call in a linted file; it now panics when the configuration is loaded — same panic, strictly earlier.

Disclosure

This change was implemented and benchmarked with AI assistance (Claude Code), and has been reviewed by the submitter.

🤖 Generated with Claude Code

[codspeed-hq]

Merging this PR will not alter performance

✅ 5 untouched benchmarks
⏩ 66 skipped benchmarks¹

---

_{Comparing perf/linter-no-require-imports-allow-regex (de87e8f) with main (8de6fca)}

Footnotes

1. 66 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[camc314]

thanks!

[camc314]

thanks!

[camc314]

Merge activity

• Jul 13, 9:27 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jul 13, 9:27 AM UTC: camc314 added this pull request to the Graphite merge queue.
• Jul 13, 9:41 AM UTC: Merged by the Graphite merge queue.