Install VueApollo in list and import page inits

What does this MR do and why?

Adds Vue.use(VueApollo) to eight page inits that construct a VueApollo provider but never install the plugin:

  • app/assets/javascripts/groups/your_work/index.js
  • app/assets/javascripts/projects/your_work/index.js
  • app/assets/javascripts/explore/groups/index.js
  • app/assets/javascripts/explore/projects/index.js
  • app/assets/javascripts/admin/groups/index/index.js
  • app/assets/javascripts/admin/projects/index/index.js
  • app/assets/javascripts/import/gitlab_project/index.js
  • app/assets/javascripts/import/url/index.js

Why this matters:

  • In Vue 2 these pages work by accident. super_sidebar_bundle.js calls Vue.use(VueApollo) at module scope and loads on every page, so the global mixin is already registered when the list app mounts.
  • In the Vue 3 realm each migrated page gets its own copy of lib/utils/vue3compat/vue_apollo.js. Its install() returns early unless Vue.use(VueApollo) ran in that realm. Nothing in these pages' module graph calls it, so this.$apollo is undefined and the shared list view fails with Cannot read properties of undefined (reading 'queries'). The header and tabs render, the list body stays empty.
  • This was found by the stress test in !255334 (closed), which promotes every page entry to Vue 3 rollout. About 70 of its 75 failing feature spec examples trace to this one gap.

The change is behaviour-neutral in Vue 2. The compat plugin dedupes repeated Vue.use(VueApollo) calls, and vue-apollo 3 ignores a second install.

Not changed here:

  • A grep finds 52 files that construct new VueApollo( without Vue.use(VueApollo). Most are client helpers or Storybook stories whose callers install the plugin. That list needs triage before any wider change.
  • A systemic fix (have the compat provider register the mixin when passed to initVueApp, or an ESLint rule) is a separate discussion.

References

Screenshots or screen recordings

No visual change in Vue 2. In Vue 3 the affected lists go from empty to rendered.

How to set up and validate locally

  1. Add vue3_migration.yml with status: rollout and feature_flag: vue3_migrate_stress_test next to app/assets/javascripts/pages/dashboard/groups/index/index.js, and define the flag as in !255334 (closed).

  2. Enable the flag and open /dashboard/groups.

  3. Without this MR the page shows the header and tabs, the counter badge shows -, and the console logs Cannot read properties of undefined (reading 'queries'). With this MR the groups list renders.

  4. Run the feature specs that failed on the stress MR, for example:

    bin/rspec spec/features/dashboard/groups_list_spec.rb spec/features/explore/groups_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code

Merge request reports

Loading
Loading