eslint-plugin-vue

Summary publish as an ESM-only package with an import-only package export migrate the package source, internal rules, tools and scripts, tests, and documentation tooling from CommonJS module syntax to native ESM require Node.js Breaking changes CommonJS consumers can no longer load the package with ; use instead Node.js versions outside the updated range are no longer supported Scope Related to #2777. This PR intentionally handles only the ESM migration; rewriting the JavaScript source in TypeScript remains out of scope. Validation

What rule do you want to change? Does this change cause the rule to produce more or fewer warnings? More. It adds detection for a case that currently passes silently. How will the change be implemented? (New option, new default behavior, etc.)? New default behavior (no new option). is sugar for a prop + emit, so mutating it in place is the same category of bug the rule already catches for . This mirrors the precedent set by #2360 and #3032, which taught other rules about . Please provide some example code that this change will affect: What does the rule currently do for this code?* Nothing — 0 errors. Verified by running the current rule (v10.10.0) via ESLint's against the parsed SFC. For comparison, the identical* mutation shape on a object IS flagged: Root cause: the rule only registers ; there is no handler, even though that visitor hook already exists. What will the rule do after it's changed? Flag the three lines as , while leaving (and the option semantics) untouched. Additional context Why it's a real bug, not style: goes through the ref setter and emits , syncing the parent. skips the setter, so no emit fires and the parent silently desyncs. Scope note: this is a syntactic check on direct mutation. It will not track mutation via an intermediate alias () — that needs data-flow analysis and I'd suggest keeping it out of scope for v1. I'm happy to open the PR (implementation + tests + docs + changeset) if this is accepted.

Refs #3130 Summary returns a ref that bridges a prop and its emit. Reassigning goes through the ref setter and emits the update, but mutating a nested property in place bypasses the setter, never emits, and silently desyncs the parent: already reports this exact class of bug for , but ignored because it only registered . This wires bindings into the same pipeline used for destructured props, via the existing hook (added in #2360). This follows the same "teach an existing rule about " pattern as #2360 and #3032. Behavior Reports nested mutation of a ref: property assignment, index assignment, arbitrary depth, /, mutating array methods (, , …), and . Allows reassigning the ref itself (), which is the correct update pattern. continues to permit nested mutation, consistent with its meaning for props. No change** to / Options API behavior. Known limitation (deliberate, out of scope for this PR) This is a syntactic check on direct mutation. It does not track mutation through an intermediate alias (), which would require data-flow analysis. Happy to note this in the docs or track it separately if preferred. Test plan [x] Added valid + invalid cases to (nested property/index/depth, mutating calls, , named model, correct-reassign patterns, unrelated locals, , and a regression guard). [x] → 288 files, 11628 tests pass. [x] on changed files and clean. [x] succeeds. [x] Added a changeset.