Retire the VTU v1 find-upgrade reliance in jest specs

Illya Klymovrequested to merge
xanf/vtu2-find-domwrapper-parity into master

What does this MR do and why?

Jest specs must not rely on the @vue/test-utils v1 "find upgrade" — string-selector find()/findAll() results silently acting as component wrappers (vm, props(), emitted(), …). VTU v2 returns a DOMWrapper there, so every such site is a latent failure for the Vue 3 jest lane.

This MR retires the pattern and keeps it retired:

  1. Static guard: local-rules/vue3-find-component-upgrade (error, autofixable) + scripts/frontend/codemods/vue3_find_component_upgrade.mjs to batch-fix and list residue.
  2. Migration: 860 files via the codemod, 83 residual sites by hand (split DOM/component finders, parameterized helpers).
  3. Runtime guard (spec/frontend/vtu1_dom_find_parity_setup.js, Vue 2 jest lane only): a jest-setup Proxy that mirrors the v2 DOMWrapper contract — component-API access on a string-selector find result throws with the selector and API named. DOM-level usage of the same wrappers is untouched. No package patching involved.

The runtime guard is the point: a first full-suite run with it exposed 582 assertions across 115 more suites reaching component APIs through indirect flows (helpers passed as values, results traversing variables/arrays/test tables) that no static rule can track. All migrated.

Verification

  • Full Vue 2 jest suite with the guard active: 6,064/6,064 suites, 90,849 tests, 0 failures — the suite itself now proves the pattern is gone.
  • Full VUE_VERSION=3 jest suite: green (identical counts).
  • Rule unit tests: 174 passing; codemod --list reports zero fixable/residual sites.

Reviewable commit-by-commit; the codemod commit can be regenerated by running the codemod.

Merge request reports