feat(biome_js_analyse): added new rule noMagicNumbers

[vladimir-ivanov]

Summary

Added noMagicNumbers rule.
The rule detects and reports the use of "magic numbers" — numeric literals that are used directly in code without being assigned to a named constant.

The no magic numbers rule ignores:

• non-magic values (like 0, 1, 2, 10, 24, 60, and their negative or bigint forms) found anywhere, including arithmetic expressions, fn calls etc.
• Array indices
• Enum values
• Initial values in variable or class property declarations
• Default values in function parameters or destructuring patterns
• Arguments to JSON.stringify and parseInt (e.g., JSON.stringify(22), parseInt("123", 25))
• Operands in bitwise operations (e.g., a & 7, a | 7)
• Values in JSX expressions (e.g., <div>{1}</div>)
• Object property values (e.g., { tax: 0.25 })

Example

let total = price * 1.23; // Magic number for tax rate will highlight 1.23 as magic number

closes #4333

[changeset-bot]

🦋 Changeset detected

Latest commit: 86af259

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@biomejs/biome	Patch
@biomejs/cli-win32-x64	Patch
@biomejs/cli-win32-arm64	Patch
@biomejs/cli-darwin-x64	Patch
@biomejs/cli-darwin-arm64	Patch
@biomejs/cli-linux-x64	Patch
@biomejs/cli-linux-arm64	Patch
@biomejs/cli-linux-x64-musl	Patch
@biomejs/cli-linux-arm64-musl	Patch
@biomejs/wasm-web	Patch
@biomejs/wasm-bundler	Patch
@biomejs/wasm-nodejs	Patch
@biomejs/backend-jsonrpc	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #6562 will not alter performance

_{Comparing vladimir-ivanov:feature/noMagicNumbers (86af259) with main (a74828c)}

Summary

✅ 115 untouched benchmarks

[ematipico]

Haven't checked the code yet. I left a couple of things to address

[vladimir-ivanov]

Haven't checked the code yet. I left a couple of things to address

addressed the ones you mentioned, thanks for the suggestions.

[arendjr]

Nice work!

Regarding "Operands in bitwise operations (e.g., a & 1, a | 2)", I personally think these shouldn't be an exception. 1 and 2 are already exceptions on their own, and more complex numbers are best assigned to a _MASK or _BITS constant IMO. Otherwise, your code is still not giving any explanation as to why these specific bits are relevant.

[vladimir-ivanov]

Nice work!

Regarding "Operands in bitwise operations (e.g., a & 1, a | 2)", I personally think these shouldn't be an exception. 1 and 2 are already exceptions on their own, and more complex numbers are best assigned to a _MASK or _BITS constant IMO. Otherwise, your code is still not giving any explanation as to why these specific bits are relevant.

RE: 1 and 2 are already exceptions on their own - you are right about 1 and 2 being non magical :-), let me update with other examples.
RE: and more complex numbers are best assigned to a _MASK or _BITS constant IMO - suggests to me we need an option for these :-)? we can introduce as part of another task?

[vladimir-ivanov]

I can now merge if it goes green right? @arendjr

[arendjr]

Yep, go for it!