<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=627892) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=627892) </details> <!--IssueSummary end--> ## Problem `app/assets/javascripts/entrypoints/performance_bar.js` line 2 imports `~/commons`. `main.js` also imports `~/commons`, and `main` is prepended to every page entry. Under regular Vue 2 execution this costs nothing: webpack uses `runtimeChunk: 'single'` and a `commons` cache group with `minChunks: 2`, and Vite serves one ESM instance per URL, so `commons/*` runs once. Under the Vue 3 rollout for the performance bar (feature flag `vue3_migrate_performance_bar`, MR !252286), the bar's entry is built with the `?vue3` marker. The infection plugin gives every infectable module below that import a second copy with a different module id, so `commons/index.js?vue3` runs again. Observed in GDK with Vite: `commons/vue.js?vue3` and `commons/duo_ui.js?vue3` load next to the plain copies. `duo_ui.js` calls `setConfigs` on the shared `@gitlab/duo-ui` registry, which throws `GitLab Duo-UI can only be configured once!` on the second call. `polyfills`, `bootstrap`, `gitlab_ui` and `lib/utils/axios_utils.js` were not duplicated because the infection plugin treats them as clean. MR !252286 works around this by adding `app/assets/javascripts/commons/duo_ui.js` to `INFECTION_BLOCKLIST` in `config/helpers/context_aliases_shared.js`. That is the minimal fix, not the structural one. `entrypoints/super_sidebar.js` has the same `import '~/commons'`, so the next global bundle to migrate meets the same problem. ## Why the import exists Commit `8e1a8deee39f` (2018, MR !6508) split the performance bar UI into a lazy chunk (now `defineAsyncComponent`, see MR !247677) but kept the wrapper eager, because `performance_bar/index.js` registers the axios interceptor and must run early in the page lifecycle. The performance bar is a standalone webpack entry, not a page entry, so `main` is not prepended to it. `app/views/layouts/_head.html.haml` renders `webpack_bundle_tag 'performance_bar'` before the page bundle from `webpack_controller_bundle_tags`. Without its own `~/commons` import, the bar cannot rely on polyfills, the jQuery and Bootstrap setup, the `Vue.use(...)` plugin registrations in `commons/vue.js`, the `@gitlab/ui` and `@gitlab/duo-ui` configuration, and the axios defaults being present before `new Vue({ el })` runs. ## Proposal - Remove `import '~/commons';` from `entrypoints/performance_bar.js`. - Decide how the bar gets its bootstrap instead. Two candidates: - Import only what the bar needs (`~/commons/vue` for the Vue plugins, `~/commons/polyfills` if still required, `~/lib/utils/axios_utils`, which it already imports). - Move the `performance_bar` script tag after the page bundle so `main` has run. - Apply the same decision to `entrypoints/super_sidebar.js`, or open a sibling issue for it. - Once the bar no longer imports `~/commons`, remove `commons/duo_ui.js` from `INFECTION_BLOCKLIST` if nothing else needs it there. ## What must stay true - The axios interceptor in `performance_bar/index.js` is registered before the page's own requests start, so the bar keeps listing the page's GraphQL requests. MR !252286 verified this with the flag on. - The bar works with the flag off (Vue 2) and on (Vue 3), under webpack, rspack and Vite. - No `commons/*` module runs twice with the flag on. Check the network log for `?vue3` copies and the console for errors. - The infection scanner's duplicated-modules check does not yet model global rollout entries (separate follow-up on the rollout issue), so verify this in the browser for now. ## Alternatives considered - Keep the import and blocklist `commons/duo_ui.js`. MR !252286 does this as the minimal fix. It leaves the mixed barrel in place. - Split `commons/index.js` into a run-once part (`polyfills`, `bootstrap`, `duo_ui`, `axios_utils`) and a per-Vue-lane part (`vue.js`, `gitlab_ui.js`). This benefits every global bundle and could be done instead of, or after, this issue. - Make `setConfigs` in `@gitlab/duo-ui` idempotent. This hides the duplication instead of removing it, and lives in another repository. ## References - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252286 — the MR that found this; carries the blocklist workaround - https://gitlab.com/gitlab-org/gitlab/-/issues/624131 — rollout issue for `vue3_migrate_performance_bar` - https://gitlab.com/gitlab-org/gitlab/-/issues/623999 — Vue 3 global bundles tracking issue - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6508 — 2018 lazy-load split that made the wrapper eager - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/247677 — `defineAsyncComponent` codemod - https://gitlab.com/gitlab-org/gitlab/-/commit/8e1a8deee39f — the 2018 commit <!-- claude session=dc8b81f3-148b-422f-affc-7e0d548190c7 posted=2026-09-07T10:05:00Z -->