biome complexity/noAdjacentSpacesInRegex: fix changes program behavior
Hypothesis Nemotron 3 Super predicted to fire fired 2×
getters, setters and Object.defineProperty side effects
Program
Output
Match: true
Match: false
- fired
- 2 before · 0 after
- runs
- each version twice, same file name, no network
Judge Nemotron 3 Ultra advisory introspection-only · low
The fix rewrites the regex literal from `/hello world/` to `/hello {2}world/`, which changes the value of `RegExp.prototype.source` that the program explicitly reads and logs. The actual matching behavior against the string `'hello world'` is unchanged; only the source text representation differs, which is expected for any rewrite of a regex literal.
Explanation Nemotron 3 Super unverified
The original regex `/hello world/` matches exactly two spaces between "hello" and "world". After rewriting to `/hello {2}world/`, it still requires exactly two spaces—so semantically equivalent in pattern—but `obj.pattern` returns `.source`, which for the first is `"hello world"` (literal two spaces) and for the second is `"hello {2}world"` (the string `{2}`). When testing `/hello world/.test(obj.pattern)`, the literal string `"hello world"` matches, but `"hello {2}world"` does not contain two consecutive spaces—it contains the characters `{`, `2`, `}`—so the test fails. The rewrite altered the source string’s content, breaking the test despite preserving regex meaning.
Reproduce
- file
prog.js(the before program)- minimized program
- r2-p001.js
- evidence sheet
- r2-p001.md
- regression fixture
- r2-p001.js the minimized program with a header stating the observed change, for the tool's test suite
node prog.js bunx @biomejs/biome lint --only=complexity/noAdjacentSpacesInRegex --write prog.js node prog.js
Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra
noAdjacentSpacesInRegex fix · complexity/noAdjacentSpacesInRegex regex literal spaces · regex test method pattern property accessor · Object.defineProperty getter returning regex source
- related biomejs/biome/issues/11419 same rule noAdjacentSpacesInRegex but different construct (character class vs plain regex)
- related biomejs/biome/issues/1704 same rule noAdjacentSpacesInRegex but different scenario (lint-on-save vs getter property)
Details
- program
- Getter/setter accessing modified regex source
- hazard
- getters, setters and Object.defineProperty side effects
- oracle
stdout before: Match: true stdout after: Match: false- run
- 2026-10-17T20-03-48-850Z-01ch-biome-complexity_noAdjacentSpacesInRegex
generated program (7 lines) and the fix's diff
--- orig.js 2026-10-17 16:04:03.154000070 -0400 +++ fixed.js 2026-10-17 16:04:03.418982422 -0400 @@ -1,7 +1,7 @@ const obj = {}; Object.defineProperty(obj, 'pattern', { - get() { return /hello world/.source; }, + get() { return /hello {2}world/.source; }, enumerable: true, configurable: true }); -console.log('Match:', /hello world/.test(obj.pattern)); +console.log('Match:', /hello {2}world/.test(obj.pattern));
rule documentation given to the models
Summary
- Name: noAdjacentSpacesInRegex
- Fix: safe
- Default severity: warn
- Available from version: 1.0.0
- Diagnostic category: lint/complexity/noAdjacentSpacesInRegex
- This rule is recommended
Description
Disallow unclear usage of consecutive space characters in regular expression literals
Examples
Invalid
```js,expect_diagnostic
/ /
```
```js,expect_diagnostic
/foo */
```
```js,expect_diagnostic
/foo {2,}bar {3,5}baz/
```
```js,expect_diagnostic
/foo [ba]r b(a|z)/
```
Valid
```js
/foo {2}bar/
```
```js
/ foo bar baz /
```
```js
/foo bar baz/
```