biome style/useNodeAssertStrict: fix changes program behavior
Hypothesis Nemotron 3 Super predicted to fire fired 1×
getters, setters and Object.defineProperty side effects
Program
Output
(no stdout) AssertionError [ERR_ASSERTION]: 99 == 42
(no stdout) AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
- fired
- 1 before · 0 after
- runs
- each version twice, same file name, no network
Judge Nemotron 3 Ultra advisory intended-change · low
The rule intentionally changes the import from `node:assert` to `node:assert/strict` to enable stricter assertions. The observed difference in error messages (loose equality vs strict equality) is exactly the semantic change the rule documents, demonstrating that the stricter assertion behavior is now active.
Explanation Nemotron 3 Super unverified
The original import uses `node:assert`, which provides loose equality checks (`==`) in methods like `equal`. The rewritten import uses `node:assert/strict`, which enforces strict equality (`===`). Since `99` (number) and `42` (number) are not strictly equal—though they are loosely equal only if type-coerced, which they aren’t here—the assertion fails with a different error message and failure mode. The change alters the semantics of the assertion, making it stricter, so the program’s behavior differs despite both throwing. This is not semantics-preserving because the condition for failure and the error details changed.
Reproduce
- file
prog.js(the before program)- minimized program
- r1-p008.js
- evidence sheet
- r1-p008.md
- regression fixture
- r1-p008.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=style/useNodeAssertStrict --write prog.js node prog.js
Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra
useNodeAssertStrict fix · style/useNodeAssertStrict setter assertion · style/useNodeAssertStrict Object.defineProperty set · style/useNodeAssertStrict import node:assert
- related biomejs/biome/issues/11455 Same rule area (node:assert imports) but different rule (noConditionalExpect) and different defect (import allowlist vs strict mode rewrite)
Details
- program
- Getter/setter side effects
- hazard
- getters, setters and Object.defineProperty side effects
- oracle
stderr before: AssertionError [ERR_ASSERTION]: 99 == 42 stderr after: AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:- run
- 2026-10-17T21-03-29-122Z-94ur-biome-style_useNodeAssertStrict
generated program (8 lines) and the fix's diff
--- orig.js 2026-10-17 17:03:44.202155390 -0400 +++ fixed.js 2026-10-17 17:03:44.480158588 -0400 @@ -5,4 +5,4 @@ }); console.log(obj.prop); obj.prop = 99; -import * as assert from "node:assert"; +import * as assert from "node:assert/strict";
rule documentation given to the models
Summary - Name: useNodeAssertStrict - Fix: safe - Default severity: warn - Available from version: 1.6.0 - Diagnostic category: lint/style/useNodeAssertStrict Description Promotes the usage of `node:assert/strict` over `node:assert`. If you prefer stricter assertions when using the Node.js assertion module, the package `node:assert/strict` exposes a set of alias for stricter assertions. Examples Invalid ```js,expect_diagnostic import * as assert from "node:assert" ``` Valid ```js import * as assert from "node:assert/strict" ```