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.jsapp/assets/javascripts/projects/your_work/index.jsapp/assets/javascripts/explore/groups/index.jsapp/assets/javascripts/explore/projects/index.jsapp/assets/javascripts/admin/groups/index/index.jsapp/assets/javascripts/admin/projects/index/index.jsapp/assets/javascripts/import/gitlab_project/index.jsapp/assets/javascripts/import/url/index.js
Why this matters:
- In Vue 2 these pages work by accident.
super_sidebar_bundle.jscallsVue.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. Itsinstall()returns early unlessVue.use(VueApollo)ran in that realm. Nothing in these pages' module graph calls it, sothis.$apollois undefined and the shared list view fails withCannot 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(withoutVue.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
- Found by the stress test MR !255334 (closed)
- Analysis comment with console errors, DOM dump and the 52-file audit: !255334 (comment 3832292473)
- Failing pipeline that surfaced it: https://gitlab.com/gitlab-org/gitlab/-/pipelines/2847726052
- Vue 3 migration epic: &23285
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
-
Add
vue3_migration.ymlwithstatus: rolloutandfeature_flag: vue3_migrate_stress_testnext toapp/assets/javascripts/pages/dashboard/groups/index/index.js, and define the flag as in !255334 (closed). -
Enable the flag and open
/dashboard/groups. -
Without this MR the page shows the header and tabs, the counter badge shows
-, and the console logsCannot read properties of undefined (reading 'queries'). With this MR the groups list renders. -
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.