.changeset/calm-rivers-flow.md (1)

5-5: Reference the tracked issue in the bug-fix line.

Per the changeset guideline, bug-fix entries should start with Fixed [#NUMBER](issue link): ... when a GitHub issue exists. Issue #9810 is referenced by this PR, so let's link it.

📝 Suggested wording

-[`noMisleadingReturnType`](https://biomejs.dev/linter/rules/no-misleading-return-type/) no longer reports false positives when a union return type's `boolean` variant is covered by both `true` and `false` returns.
+Fixed [`#9810`](https://github.com/biomejs/biome/issues/9810): [`noMisleadingReturnType`](https://biomejs.dev/linter/rules/no-misleading-return-type/) no longer reports false positives when a union return type's `boolean` variant is covered by both `true` and `false` returns.

As per coding guidelines: "For changeset descriptions of bug fixes, reference the issue with a link (e.g., 'Fixed #4444')".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.changeset/calm-rivers-flow.md at line 5, Update the changeset entry for the
bug fix so the description starts with the required "Fixed
[`#9810`](https://github.com/your-repo/issues/9810):" prefix; specifically edit
the .changeset/calm-rivers-flow.md line that mentions the noMisleadingReturnType
rule and replace the current sentence with one beginning "Fixed
[`#9810`](https://github.com/your-repo/issues/9810): noMisleadingReturnType no
longer reports false positives when a union return type's `boolean` variant is
covered by both `true` and `false` returns." Ensure the issue number and URL are
correct and keep the rest of the text unchanged.

crates/biome_js_analyze/src/lint/nursery/no_misleading_return_type.rs (1)

602-602: Tiny doc nit. The comment links [TypeData::union_of] — double-check the intra-doc link resolves (i.e. union_of is pub on TypeData), otherwise cargo doc will warn.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/no_misleading_return_type.rs` at
line 602, The doc comment references TypeData::union_of but may produce a broken
intra-doc link; verify that the method/associated function union_of on TypeData
is exported (pub) and that the path matches the actual symbol name, and if it is
not public either make union_of pub or update the comment to point to the
correct public item (or use plain text) so the intra-doc link resolves without
cargo doc warnings; check the TypeData type and the union_of item name to ensure
the link syntax [`TypeData::union_of`] is correct.

crates/biome_js_type_info/src/type.rs (1)

92-116: Same algorithm, second copy.

This mirrors normalize_boolean_union_variants in crates/biome_js_type_info/src/helpers.rs, just at the Type level instead of TypeReference. Functionally fine, but keeping the two implementations in lock-step is on us forever — worth a follow-up to extract the shared classification (has_boolean / has_true / has_false → action) so a future tweak only has to land in one place.

Also: the template dance is only needed to inherit a resolver for with_id. If you exposed something like Type::from_id(self.resolver.clone(), GLOBAL_BOOLEAN_ID) at this call site, you could skip the find(...).cloned() step entirely.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/type.rs` around lines 92 - 116, Extract the
duplicated boolean-union classification logic (has_boolean / has_true /
has_false → action) from normalized_boolean_union_variants in Type (and the
existing normalize_boolean_union_variants in helpers.rs) into a shared helper
function used by both Type and TypeReference so future changes land in one
place; additionally add a constructor/associated fn on Type (e.g. Type::from_id
taking a resolver and GLOBAL_BOOLEAN_ID) so normalized_boolean_union_variants
can construct the boolean Type directly instead of doing the current template
find().cloned() + with_id dance, then update normalized_boolean_union_variants
to call the shared classifier and use Type::from_id(GLOBAL_BOOLEAN_ID) (or
equivalent) when injecting the boolean variant.

crates/biome_js_type_info/src/helpers.rs (1)

327-353: Logic is correct, a couple of small polish opportunities.

• !(has_boolean || has_true && has_false) parses as !(has_boolean || (has_true && has_false)) thanks to && binding tighter than ||. Adding parens would save the next reader a trip to the precedence table.
• Each any(...) re-calls resolver.resolve_and_get(ty) — a single pass classifying every variant once would do the same job with one resolution per entry.
• This is conceptually the same algorithm as Type::normalized_boolean_union_variants in type.rs. Worth a TODO to share a single source of truth eventually.

♻️ Suggested clarity tweak

-    if !(has_boolean || has_true && has_false) {
+    if !(has_boolean || (has_true && has_false)) {
         return;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/helpers.rs` around lines 327 - 353, In
normalize_boolean_union_variants: add parentheses around the conditional check
to make the intent explicit (e.g. !(has_boolean || (has_true && has_false)));
then refactor the logic to do a single pass over variants calling
resolver.resolve_and_get once per entry to classify each variant into boolean
keyword / true literal / false literal (use is_boolean_keyword_reference and
is_boolean_literal_reference semantics) while building a new retained list
without boolean literals; after the pass, set has_boolean/has_true/has_false
from those flags, replace variants with the retained list, and if !has_boolean
but has_true && has_false push TypeReference::Resolved(GLOBAL_BOOLEAN_ID); add a
TODO note referencing Type::normalized_boolean_union_variants in type.rs for
future sharing of logic.

crates/biome_js_type_info/src/helpers.rs (2)

327-378: Note the parallel implementation in type.rs.

Type::normalized_boolean_union_variants (in crates/biome_js_type_info/src/type.rs) implements the exact same canonicalisation rule on a Vec<Type> instead of Vec<TypeReference>. Two sources of truth for the same invariant is a minor maintenance hazard — if one is later tweaked (e.g. to also collapse boolean | true | false differently), the other will silently drift. Worth a short doc comment cross-referencing them so future maintainers know to keep them in sync, or extracting the shared "(has_boolean, has_true, has_false) → action" decision into a tiny helper. Not a blocker.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/helpers.rs` around lines 327 - 378, The
boolean-union canonicalization in normalize_boolean_union_variants duplicates
the logic in Type::normalized_boolean_union_variants; either add a short doc
comment on normalize_boolean_union_variants that cross-references
Type::normalized_boolean_union_variants (and vice‑versa) so maintainers know
they must stay in sync, or refactor the shared decision logic (the
has_boolean/has_true/has_false detection and resulting action) into a tiny
shared helper used by both normalize_boolean_union_variants and
Type::normalized_boolean_union_variants to avoid two sources of truth.

---

330-356: Optional: collapse the three scans into one.

has_boolean, has_true, and has_false each iterate variants and resolve every reference independently — three resolver lookups per element before we even get to retain. A single pass would be cheaper and arguably clearer. Logic-wise the current code is correct (operator precedence in the early-return condition is fine).

♻️ Suggested single-pass variant

-    let has_boolean = variants
-        .iter()
-        .any(|ty| is_boolean_keyword_reference(resolver, ty));
-    let has_true = variants
-        .iter()
-        .any(|ty| is_boolean_literal_reference(resolver, ty, true));
-    let has_false = variants
-        .iter()
-        .any(|ty| is_boolean_literal_reference(resolver, ty, false));
+    let (mut has_boolean, mut has_true, mut has_false) = (false, false, false);
+    for ty in variants.iter() {
+        match resolver.resolve_and_get(ty).as_ref().map(|r| r.as_raw_data()) {
+            Some(TypeData::Boolean) => has_boolean = true,
+            Some(TypeData::Literal(lit)) => match lit.as_ref() {
+                Literal::Boolean(b) if b.as_bool() => has_true = true,
+                Literal::Boolean(_) => has_false = true,
+                _ => {}
+            },
+            _ => {}
+        }
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/helpers.rs` around lines 330 - 356, The three
separate scans in normalize_boolean_union_variants are inefficient; replace them
with a single pass over variants that checks each TypeReference once using
is_boolean_keyword_reference and is_boolean_literal_reference to set
has_boolean, has_true, and has_false flags (and optionally mark which indexes
are literal true/false). After the single pass, use the same early-return logic
(if !(has_boolean || (has_true && has_false)) return), then remove boolean
literal references (e.g., via variants.retain or by constructing a filtered Vec)
and, if has_boolean is false, push TypeReference::Resolved(GLOBAL_BOOLEAN_ID);
keep the function name and calls to is_boolean_keyword_reference,
is_boolean_literal_reference, and GLOBAL_BOOLEAN_ID unchanged.

crates/biome_js_analyze/tests/specs/nursery/noMisleadingReturnType/valid.ts (1)

161-174: Solid valid-case set; one nit on placement.

The five new cases — including duplicateBooleanReturns to verify dedup before canonicalisation — give good coverage. Minor nit: they're inserted between storeObj (line 159) and StaticStore (line 175), which splits the "getter + setter" cluster. Consider moving the boolean-union block to the end of the file (after StaticStore) so related groups stay contiguous. Non-blocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/tests/specs/nursery/noMisleadingReturnType/valid.ts`
around lines 161 - 174, The added boolean-union test cases (useCloudLogin,
booleanOrUndefined, booleanOrLiteral, nullOrBoolean, duplicateBooleanReturns)
are placed between the related "getter + setter" cluster (storeObj and
StaticStore); move this entire block of five functions so it appears after the
StaticStore block (i.e., append the boolean-union block to the end of the file
after the StaticStore declaration) to keep related test groups contiguous.

crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs (1)

254-275: Tiny nit: rename the loop binding.

for ty in &state.missing_cases reads a bit oddly now that the element type is MissingCase, not Type. Renaming to case (matching the helper parameter names below) keeps things consistent.

♻️ Suggested rename

-        for ty in &state.missing_cases {
+        for case in &state.missing_cases {
@@
-                missing_case_to_expression(ty)?,
+                missing_case_to_expression(case)?,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 254 - 275, Rename the loop binding `ty` in the `for ty in
&state.missing_cases` loop to `case` (or `missing_case`) to reflect the element
type `MissingCase` and match the helper names like `missing_case_to_expression`;
update the loop header and all uses of `ty` inside the loop (where you call
`missing_case_to_expression(ty)?`, build the `case_token`, construct the
`AnyJsSwitchClause::JsCaseClause` via `make::js_case_clause`, and when pushing
to `clauses`) so names are consistent and clearer.

crates/biome_js_type_info/src/type.rs (1)

87-116: Mirrors helpers.rs::normalize_boolean_union_variants — cross-link them.

This Type-level helper duplicates the canonicalisation already performed inside TypeData::union_of (via helpers.rs::normalize_boolean_union_variants). The two will run on different inputs (already-resolved Type values vs raw TypeReferences during union construction), so consolidating fully is awkward, but at minimum a doc-comment cross-reference would help future maintainers keep the rules in sync.

Also: the template dance is fine, but since you've established that has_true && has_false holds in the !has_boolean branch, the find is guaranteed to return Some. A tiny readability win is to express that without the Option<Option<_>> flatten:

♻️ Slightly tidier template extraction

-        let template = (!has_boolean)
-            .then(|| {
-                types
-                    .iter()
-                    .find(|ty| ty.is_boolean_literal(true) || ty.is_boolean_literal(false))
-                    .cloned()
-            })
-            .flatten();
+        let template = (!has_boolean).then(|| {
+            types
+                .iter()
+                .find(|ty| ty.is_boolean_literal(true) || ty.is_boolean_literal(false))
+                .cloned()
+                .expect("has_true && has_false implies a literal variant exists")
+        });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/type.rs` around lines 87 - 116, Add a
doc-comment cross-reference in Type::normalized_boolean_union_variants pointing
to helpers.rs::normalize_boolean_union_variants so maintainers know these two
routines implement the same canonicalization rules, and simplify the template
extraction: replace the current Option<Option> flatten pattern by directly
finding and cloning the boolean literal (use find(...).cloned().expect(...) or
equivalent) inside the (!has_boolean) branch because has_true && has_false
guarantees a match; keep the subsequent retain(...) and
push(template.with_id(...)) behavior intact.

crates/biome_js_type_info/src/type.rs (2)

73-85: with_id: nice helper, soft contract worth flagging.

The debug_assert! is great for tests but in release builds an unknown id silently degrades to UNKNOWN_DATA via Deref. Today the only caller passes GLOBAL_BOOLEAN_ID, which any sane resolver in this codebase resolves, so this is fine. If with_id ever becomes public-facing for arbitrary ids, consider returning Option<Self> instead.

Also, the doc comment mentions only "predefined global ID" — works for now, but future callers may want a clearer rule.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/type.rs` around lines 73 - 85, The current
Type::with_id uses a debug_assert! to check resolver can resolve the provided
ResolvedTypeId, which is silent in release builds and can lead to UNKNOWN_DATA;
change the API to return Option<Self> (or Result<Self, ...>) instead of Self so
callers must handle unknown ids—update the function signature of with_id to
return Option<Type>, perform a runtime check using
self.resolver.get_by_resolved_id(id).is_some() and return Some(Self { resolver:
self.resolver.clone(), id }) or None; update callers (e.g., where
GLOBAL_BOOLEAN_ID is used) to unwrap or handle the Option and amend the doc
comment to state the contract clearly (that callers must supply a resolver-known
ResolvedTypeId or handle None).

---

94-129: Logic checks out across the four interesting shapes.

Walked through true|false, boolean|true, boolean|true|false, and boolean alone — all collapse correctly, and the seen_boolean retain dedupes aliased Boolean references to one. 👍

Minor:

• Same readability tweak as helpers.rs: !(has_boolean || (has_true && has_false)) parses faster.
• crate::globals_ids::GLOBAL_BOOLEAN_ID could just be added to the existing use crate::globals::{ ... } block (it's re-exported there) to avoid the inline path:

 use crate::globals::{
-    GLOBAL_ARRAY_ID, GLOBAL_ASYNC_DISPOSABLE_ID, GLOBAL_DISPOSABLE_ID, GLOBAL_NUMBER_ID,
+    GLOBAL_ARRAY_ID, GLOBAL_ASYNC_DISPOSABLE_ID, GLOBAL_BOOLEAN_ID, GLOBAL_DISPOSABLE_ID, GLOBAL_NUMBER_ID,
     GLOBAL_PROMISE_ID, GLOBAL_STRING_ID, GLOBAL_SYMBOL_ASYNC_DISPOSE_ID,
     GLOBAL_SYMBOL_DISPOSE_ID, GLOBAL_UNKNOWN_ID,
 },

-            types.push(template.with_id(crate::globals_ids::GLOBAL_BOOLEAN_ID));
+            types.push(template.with_id(GLOBAL_BOOLEAN_ID));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/type.rs` around lines 94 - 129, The function
normalized_boolean_union_variants is fine but please apply two small readability
tweaks: (1) change the conditional !(has_boolean || has_true && has_false) to
the clearer form !(has_boolean || (has_true && has_false)) around the
early-return so the precedence is explicit, and (2) replace the inline path
crate::globals_ids::GLOBAL_BOOLEAN_ID by importing GLOBAL_BOOLEAN_ID from the
crate::globals re-export (add GLOBAL_BOOLEAN_ID to the existing use
crate::globals::{ ... } block) and then use GLOBAL_BOOLEAN_ID in the types.push
call.

crates/biome_js_type_info/src/helpers.rs (2)

327-378: Heads-up: this duplicates Type::normalized_boolean_union_variants in type.rs.

Same algorithm, different value type (TypeReference vs Type). Not a blocker — they operate at different layers — but if it ever drifts, the lints will silently diverge from union_of. Worth a small shared primitive (e.g. a generic helper taking is_boolean/is_literal/make_boolean closures) at some point.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/helpers.rs` around lines 327 - 378, The logic
in normalize_boolean_union_variants (helpers.rs) duplicates
Type::normalized_boolean_union_variants (type.rs); extract the shared algorithm
into a single generic helper that both layers call by parameterizing the
type-specific checks/constructors via closures (e.g., take is_boolean_predicate,
is_literal_predicate, and make_boolean_constructor closures) and then replace
normalize_boolean_union_variants and Type::normalized_boolean_union_variants to
invoke that helper; reference the existing helpers is_boolean_literal_reference
and is_boolean_keyword_reference as the predicates to wire into the new generic
function so both implementations reuse the same canonicalization logic.

---

327-378: Logic is correct; readability nit on the early-return condition.

The four-case truth table checks out (boolean alone, true|false, boolean|true, neither). Two small suggestions:

1. !(has_boolean || has_true && has_false) relies on && binding tighter than ||. It's correct but a quick parenthesis makes it scan instantly:

-    if !(has_boolean || has_true && has_false) {
+    if !(has_boolean || (has_true && has_false)) {
         return;
     }

2. Three full passes of iter().any(...) over variants before the retain could fold into one loop. Not a hot path today, so feel free to defer.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_type_info/src/helpers.rs` around lines 327 - 378, In
normalize_boolean_union_variants the early-return condition is correct but
ambiguous; change the if condition to use explicit parentheses (e.g., if
!(has_boolean || (has_true && has_false)) ) for clarity. Optionally, to avoid
three separate iter().any passes, replace the three .any calls with a single
loop over variants that sets has_boolean, has_true and has_false flags (still
using is_boolean_keyword_reference and is_boolean_literal_reference) before the
early return and retain logic.

crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs (1)

158-163: Nit: match on a bool reads a bit awkwardly.

A plain if/else is more idiomatic here (and Clippy tends to grumble about match true => … false => …). Same applies to lines 330–333 and the inner pattern at 343–346, if you want to harmonise them.

♻️ Suggested tweak

-        let variants = match discriminant_ty.is_union() {
-            true => Type::normalized_boolean_union_variants(
-                discriminant_ty.flattened_union_variants().collect(),
-            ),
-            false => vec![discriminant_ty],
-        };
+        let variants = if discriminant_ty.is_union() {
+            Type::normalized_boolean_union_variants(
+                discriminant_ty.flattened_union_variants().collect(),
+            )
+        } else {
+            vec![discriminant_ty]
+        };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 158 - 163, The current code uses match on a boolean to set variants
(matching discriminant_ty.is_union()), which is awkward; replace the match
expression that assigns variants with an idiomatic if/else using
discriminant_ty.is_union() to choose between
Type::normalized_boolean_union_variants(...) and vec![discriminant_ty]; apply
the same refactor to the other occurrences mentioned (the block using
discriminant_ty.is_union() at the locations corresponding to lines ~330–333 and
the inner pattern around ~343–346) so all boolean matches become simple if/else
branches referencing the same expressions.

crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs (3)

160-165: Tiny nit: match on a bool reads as if/else.

match discriminant_ty.is_union() { true => ..., false => ... } is the pattern clippy::match_bool lints against. An if/else is a touch friendlier here, but feel free to ignore.

♻️ Optional cleanup

-        let variants = match discriminant_ty.is_union() {
-            true => Type::normalized_boolean_union_variants(
-                discriminant_ty.flattened_union_variants().collect(),
-            ),
-            false => vec![discriminant_ty],
-        };
+        let variants = if discriminant_ty.is_union() {
+            Type::normalized_boolean_union_variants(
+                discriminant_ty.flattened_union_variants().collect(),
+            )
+        } else {
+            vec![discriminant_ty]
+        };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 160 - 165, The match on a boolean here is clearer as an if/else:
replace the match on discriminant_ty.is_union() that sets variants with an if
discriminant_ty.is_union() { /* call Type::normalized_boolean_union_variants
with discriminant_ty.flattened_union_variants().collect() */ } else {
vec![discriminant_ty] }; keep the same calls to
Type::normalized_boolean_union_variants and
discriminant_ty.flattened_union_variants() so only the control structure for
computing variants (the variable named variants) is changed from match to an
if/else.

---

260-281: Variable name nit: ty no longer holds a Type.

Now that state: &Vec<MissingCase>, calling the loop variable ty is a small leftover from the old shape. Renaming to case (or missing) matches the new type and the surrounding missing_case_to_expression call.

-        for ty in state {
+        for case in state {
             ...
-                missing_case_to_expression(ty)?,
+                missing_case_to_expression(case)?,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 260 - 281, Loop variable `ty` no longer represents a Type; rename
it to something like `case` or `missing` in the for loop that iterates over
`state: &Vec<MissingCase>` and update all usages inside that loop (including the
call to `missing_case_to_expression(ty)?` and any references when building
`case_token` and `clause`) to the new name so the identifier matches the
`MissingCase` semantics.

---

307-312: Simplify using is_some_and.

The .and_then(|literal| Some(literal.value_token().ok()?.kind() == T![true])) is harder to read than necessary — you're opening a Some(...) just to use ? inside it. Since the project targets Rust 1.94.1, is_some_and (stable since 1.70.0) makes this much cleaner:

♻️ Suggested refactor

 fn is_true_literal_expression(expr: &AnyJsExpression) -> bool {
     expr.as_any_js_literal_expression()
         .and_then(|literal| literal.as_js_boolean_literal_expression())
-        .and_then(|literal| Some(literal.value_token().ok()?.kind() == T![true]))
-        .unwrap_or_default()
+        .and_then(|literal| literal.value_token().ok())
+        .is_some_and(|token| token.kind() == T![true])
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 307 - 312, The helper is_true_literal_expression has an unnecessary
and_then wrapping a Some(...) to use `?`; replace the third combinator with
`is_some_and` to directly test the boolean literal token kind. Specifically, in
is_true_literal_expression change the chain that calls
as_js_boolean_literal_expression() and then the and_then(|literal|
Some(literal.value_token().ok()?.kind() == T![true])) to use
is_some_and(|literal| literal.value_token().ok().map(|t| t.kind() ==
T![true]).unwrap_or(false)) or preferably is_some_and(|literal|
literal.value_token().ok().map(|t| t.kind() == T![true]).unwrap_or_default()) so
the result is a simple boolean without creating an inner Some.

crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs (4)

107-110: Consider moving MissingCase below the impl Rule block.

Per project convention, helper structs/enums belong below the rule's impl block. The documented exception is for node unions used in the rule's Query type, but MissingCase is the State type, so it doesn't qualify.

Based on learnings from PR 8960: "all helper functions, structs, and enums must be placed below the impl Rule block. The only exception is when declaring a node union to use in the rule's Query type".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 107 - 110, The enum MissingCase (used as the rule's State) should
be moved below the impl Rule block to follow project convention for helper
types; locate the MissingCase declaration and cut/paste it so it appears after
the impl Rule { ... } implementation (not before), ensuring any references to
MissingCase in the rule's State/Query remain unchanged and compile.

---

159-164: Prefer if/else over match on a bool.

Slightly more idiomatic and saves a level of indentation:

♻️ Suggested tweak

-        let variants = match discriminant_ty.is_union() {
-            true => Type::normalized_boolean_union_variants(
-                discriminant_ty.flattened_union_variants().collect(),
-            ),
-            false => vec![discriminant_ty],
-        };
+        let variants = if discriminant_ty.is_union() {
+            Type::normalized_boolean_union_variants(
+                discriminant_ty.flattened_union_variants().collect(),
+            )
+        } else {
+            vec![discriminant_ty]
+        };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 159 - 164, Replace the match on the boolean returned by
discriminant_ty.is_union() with an if/else for clarity and to remove an
unnecessary match; specifically, in the block that defines variants (currently
using match discriminant_ty.is_union()), use if discriminant_ty.is_union() {
Type::normalized_boolean_union_variants(discriminant_ty.flattened_union_variants().collect())
} else { vec![discriminant_ty] } so the logic around discriminant_ty,
normalized_boolean_union_variants, and flattened_union_variants remains the same
but uses an idiomatic if/else.

---

259-280: Rename loop binding ty → case (or missing).

state is now Vec<MissingCase>, so ty is a touch misleading at the action site. Cosmetic only.

♻️ Suggested tweak

-        for ty in state {
+        for case in state {
@@
-                missing_case_to_expression(ty)?,
+                missing_case_to_expression(case)?,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 259 - 280, The loop variable name `ty` is misleading because
`state` is a Vec<MissingCase>; rename the binding to `case` (or `missing`) in
the for loop and update all uses inside the block — e.g., change `for ty in
state {` to `for case in state {` and replace `missing_case_to_expression(ty)?`
with `missing_case_to_expression(case)?` (also update any other occurrences of
`ty` inside this block such as in the `clause` construction that references
`throw_stmt`/`clauses`), keeping the same logic and types.

---

166-188: Stale variable name: intersection_part is now a union variant.

Since the loop iterates over union variants (post normalized_boolean_union_variants), variant would read more truthfully than intersection_part. Purely cosmetic.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_js_analyze/src/lint/nursery/use_exhaustive_switch_cases.rs`
around lines 166 - 188, The loop variable name intersection_part is misleading
now that it iterates union variants; rename the loop variable to variant and
update all uses accordingly (e.g., change for intersection_part in variants to
for variant in variants, then call flatten_type(&variant) and update subsequent
checks and contains calls to use the new name or a clearly named flattened
variable such as flat_variant), ensuring references to has_boolean_case,
missing_cases.push(MissingCase::BooleanLiteral(...)), found_cases.contains(...),
and missing_cases.push(MissingCase::Type(...)) use the updated identifier names
so the code remains correct and readable.