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

102-229: Accessor / StaticAccessor / etc. groups are in default_order() but never classified.

classify_member maps getters → GetAccessor* and setters → SetAccessor*, but never returns the combined Accessor* variants. Those combined groups occupy rank positions in the default order, effectively acting as dead slots. This isn't a bug per se, but it means the combined accessor groups are only useful in custom configurations, which could confuse users expecting them to work out of the box.

Consider either documenting this clearly or removing the combined accessor entries from default_order().

crates/biome_rule_options/src/use_member_ordering.rs (1)

134-192: default_order() allocates a new Vec on every call — consider a static slice.

groups() calls default_order() which builds a fresh 44-element Vec each time. Since the default never changes, a &'static [MemberGroup] constant would avoid the allocation entirely and let groups() return a Vec only when the user provides a custom order.

Not urgent — this is called once per class — but it's a tidy improvement.

Sketch

const DEFAULT_ORDER: &[MemberGroup] = &[
    MemberGroup::IndexSignature,
    MemberGroup::StaticIndexSignature,
    // ... all variants ...
    MemberGroup::StaticBlock,
];

impl MemberGroup {
    pub fn default_order() -> &'static [MemberGroup] {
        DEFAULT_ORDER
    }
}

Then adjust groups() and rank() signatures to accept &[MemberGroup] (which they already do on the consumer side).

crates/biome_js_analyze/src/lint/nursery/use_member_ordering.rs (2)

117-244: Consider extracting shared classification logic to reduce repetition.

The property, method, getter, and setter branches all follow the same pattern: extract is_static, is_hash_private, accessibility, then call resolve_*_group. A small generic helper could collapse these ~120 lines significantly. Not urgent, but would help maintainability as the rule evolves.

---

263-370: Could reduce boilerplate with a declarative macro.

The five has_static_modifier_* and four get_*_accessibility functions are structurally identical — only the types and variants differ. A small macro_rules! could generate them all. Purely optional, but would cut ~100 lines.

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

258-365: Consider a macro to reduce the modifier-helper boilerplate.

Five has_static_modifier_* and four get_*_accessibility functions are structurally identical, differing only in the modifier list type and variant path. A declarative macro could generate all of them from a table of (fn_name, list_type, variant_prefix) tuples, cutting ~110 lines down to ~20.

Not blocking — the current code is correct and the types unfortunately don't share a trait.

crates/biome_rule_options/src/use_member_ordering.rs (1)

136-192: Consider making default_order a const or LazyLock<Vec<…>>.

default_order() allocates a fresh Vec of ~43 elements on every call. It's invoked in both run() and diagnostic() (the latter once per violation). For a class with many members, this could mean several allocations of the same data.

A const array or a static LazyLock would avoid the repeated heap allocation.

♻️ Sketch using a const array

-    pub fn default_order() -> Vec<MemberGroup> {
-        vec![
+    pub const DEFAULT_ORDER: &'static [MemberGroup] = &[
             // Index signatures
             MemberGroup::IndexSignature,
             MemberGroup::StaticIndexSignature,
             // ...same entries...
             MemberGroup::StaticBlock,
-        ]
-    }
+    ];
+
+    pub fn default_order() -> Vec<MemberGroup> {
+        Self::DEFAULT_ORDER.to_vec()
+    }

Then the callers that only need &[MemberGroup] can reference the const directly.

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

126-149: Diagnostic recomputes groups() and deduplication for every violation.

options.groups() clones the full Vec<MemberGroup> and the broad-category dedup loop runs on each diagnostic() invocation. For a class with many out-of-order members, this is repeated work. Consider caching the order description string in MemberOrderViolation or computing it once via a shared approach.

crates/biome_js_analyze/src/lint/nursery/use_member_ordering.rs (2)

310-403: Consider reducing modifier-helper duplication with a macro or trait.

There are 8 near-identical functions for extracting static/accessibility info from different modifier list types. A small declarative macro could collapse them:

💡 Sketch

macro_rules! impl_modifier_helpers {
    ($static_fn:ident, $acc_fn:ident, $list_ty:ty, $mod_enum:path, $static_variant:pat, $acc_variant:pat) => {
        fn $static_fn(modifiers: &$list_ty) -> bool {
            modifiers.into_iter().any(|m| matches!(m, $static_variant))
        }
        fn $acc_fn(modifiers: &$list_ty) -> Accessibility {
            for m in modifiers {
                if let $acc_variant = m {
                    return ts_accessibility_to_enum(&acc);
                }
            }
            Accessibility::Public
        }
    };
}

Entirely optional — the current code is clear and the repetition mirrors biome's typed-AST style.

🤖 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_member_ordering.rs` around lines
310 - 403, The eight near-identical helper functions
(has_static_modifier_property, get_property_accessibility,
has_static_modifier_method, get_method_accessibility, has_static_modifier_index,
has_static_modifier_ts_property, get_ts_property_accessibility,
has_static_modifier_ts_method, get_ts_method_accessibility) can be collapsed
with a small declarative macro to remove duplication; add a macro (e.g.,
impl_modifier_helpers) that takes the static fn name, accessibility fn name, the
modifier list type, the modifier enum path, the static variant pattern and the
accessibility variant pattern and expands to the two functions (static check
using .into_iter().any(|m| matches!(m, $static_variant)) and accessibility
getter iterating and returning ts_accessibility_to_enum when matching
$acc_variant, defaulting to Accessibility::Public) and replace the explicit
implementations with macro invocations for each modifier-list type.

---

128-151: Diagnostic rebuilds the category list on every invocation.

diagnostic() recomputes options.groups() and the seen broad-category list for each violation. For the typical number of violations per class this is negligible, but if you ever want to tighten it up, the list could be computed once in run() and stored alongside each MemberOrderViolation.

🤖 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_member_ordering.rs` around lines
128 - 151, The diagnostic() function recomputes options.groups() and the seen
broad-category list for every violation; instead, compute the ordered
broad-category list once in run() and attach it to the rule state or each
MemberOrderViolation so diagnostic() can reuse it. Update run() (where
MemberOrderViolation instances are created) to build the unique seen Vec from
ctx.options().groups() and store that Vec on the State or include it as a field
on MemberOrderViolation; then change diagnostic() to read that precomputed list
(instead of recomputing options.groups() and rebuilding seen) while still using
state.member_range and state.expected_before_name for the diagnostic text.