What causes "Unexpected side effect in "{key}" computed property." in oxc-project/oxc?

Move the mutation out of the computed — do writes in a method, watcher (`watch`), or event handler instead.

oxc-project/oxc · warning · OxcDiagnostic

Unexpected side effect in "{key}" computed property.

Error message

Unexpected side effect in "{key}" computed property.

What it means

The named-key diagnostic of vue/no-side-effects-in-computed-properties: 'Unexpected side effect in "{key}" computed property.' Computed properties must be pure — Vue caches them and re-evaluates only when reactive deps change, so assignments or other mutations inside a computed cause extra renders, 'computed was written to' warnings, or infinite update loops. The rule locates computed properties via ComputedContext/find_computed_context in objects recognized as component options and inspects their bodies (including `this.` object usage via is_this_object) for side effects.

Source

Thrown at crates/oxc_linter/src/rules/vue/no_side_effects_in_computed_properties.rs:20

    AstKind,
    ast::{CallExpression, Expression, IdentifierReference, UnaryOperator},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{
    AstNode,
    context::LintContext,
    frameworks::FrameworkOptions,
    rule::Rule,
    utils::{
        ComputedContext, find_computed_context, is_this_object, is_vue_component_options_object,
    },
};

fn unexpected_side_effect_in_property(span: Span, key: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Unexpected side effect in \"{key}\" computed property."))
        .with_label(span)
}

fn unexpected_side_effect_in_function(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Unexpected side effect in computed function.").with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoSideEffectsInComputedProperties;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Disallow side effects in computed properties.
    ///
    /// ### Why is this bad?
    ///
    /// It is considered a very bad practice to introduce side effects inside computed properties.

View on GitHub (pinned to e1e7af627c)

Solutions

Move the mutation out of the computed — do writes in a method, watcher (`watch`), or event handler instead.
If you need get/set behavior, use a writable computed with an explicit `set` function and keep the `get` pure.
Derive intermediate values with additional pure computeds rather than storing them in `data`.
Re-run oxlint to confirm.

Example fix

// before
computed: {
  normalized: {
    get() {
      this.cache = this.raw.trim(); // side effect
      return this.cache;
    }
  }
}

// after
computed: {
  normalized() {
    return this.raw.trim();
  }
}

Defensive patterns

Strategy: validation

Prevention

Keep computed getters pure: read reactive state, return a value, nothing else.
Use a writable computed's `set` (or a method/watcher) for writes.
Enable this rule in CI to catch 'computed wrote back' patterns during review.

When it happens

Trigger: An object-syntax computed like `computed: { fullName: { get() { ...; this.firstName = x; return ... } } }` — any assignment, `this.someProp = ...`, or state-mutating call inside the getter, reported with the property's key name.

Common situations: Getters that 'normalize and store' the result on the instance; writing back a formatted value inside the computed that reads it; cache-invalidation hacks inside getters; code moved out of methods into computed during refactors.

Related errors

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/cb8e92314dc45acc. Report an issue: GitHub.