Draft: Move the Jira Connect app from a global bundle to a page entry

Miguel Rinconrequested to merge
jira-connect-subscriptions-page-entry into jira-connect-subscriptions-feature-spec

What does this MR do and why?

Moves the GitLab for Jira Cloud app from the hand-written jira_connect_app global bundle to a normal page entry at pages/jira_connect/subscriptions.

Stacked on !258657 (merged), which adds the feature spec that this change is verified against. Merge that one first.

Why

jira_connect_app was the only global bundle rendered by a single view for a single route. It was declared by hand in config/helpers/entry_points.js in 2020 because the app lived outside pages/ at the time, and the manual entry followed it through later moves. Every other page gets its entry generated from its pages/**/index.js. Being a global bundle meant:

  • its vue3_migration.yml needed the <name>.vue3_migration.yml form and an entry pointing at the entrypoints/ wrapper
  • the stats script needed an ownership override because no route resolves to a global bundle
  • the docs had to list it among the layout-level bundles

After this MR, the app is an ordinary page and none of that is needed.

What changes

  • pages/jira_connect/subscriptions/index.js imports the app. The vue3_migration.yml moves next to it under the bare name. Same flag, same status.
  • The jira_connect layout renders the page bundle the way layouts/_head does. The view no longer calls webpack_bundle_tag.
  • The entrypoints/jira_connect_app.js wrapper, its yml, the entry declaration, the stats override and the docs mention go away.

Behaviour change: main.js now runs on the page

Under webpack, every page entry has main.js prepended. Under Vite, layouts/_vite_main loads it as its own script. So the Jira Cloud app now runs GitLab's shared page initialisation inside the Atlassian iframe, which it did not before.

Two consequences:

  • The app used to bootstrap itself: setConfigs() from GitLab UI, Vue.use(Translate) and the ~/webpack public-path import. main.js does all three through commons/, and calling setConfigs() twice throws GitLab UI can only be configured once!. The feature spec's console-error check caught this on the first run. The app's own calls are removed. A side effect is that GitLab UI now gets the full GitLab config, including translated component strings, instead of the library defaults.
  • The page loads more JavaScript. The bundle size report on this MR will show the pages.jira_connect.subscriptions entry against the old jira_connect_app one.

Everything else in main.js guards on DOM that this layout does not have, and the manual check below found no console errors from it.

Verification

Feature specs on GDK

bin/rspec spec/features/jira_connect/

10 examples, 0 failures on an earlier version of this branch, when user_views_subscriptions_spec.rb still ran under both bundles: those five, the four CSP examples, and the branch-creation spec. The spec was since reduced to the Vue 3 build only, two examples with the same assertions and setup, and has not been rerun on this exact tip. The pipeline on this MR runs it.

Also green: spec/lib/gitlab/vue3_migration_spec.rb, spec/lib/gitlab/vue3_migration_files_spec.rb, spec/helpers/webpack_helper_spec.rb, and the 25 Jest suites under spec/frontend/jira_connect.

Manual check on GDK, Vite

Loaded in Playwright with window.AP stubbed, once per flag state. page-initialised is the class main.js adds to body when its deferred initialisation finishes.

Flag Scripts [data-gitlab-vue3-app] page-initialised Console errors
off main.js, pages.jira_connect.js, pages.jira_connect.subscriptions.js, pages.jira_connect.subscriptions.index.js 0 yes none from the app
on same, with pages.jira_connect.subscriptions.vue3.js 1 yes none
Flag off, Vue 2
Vue 2
Flag on, Vue 3
Vue 3

The pre-existing publicKeyStorageEnabled prop warning from the stacked MR still appears under Vue 2. It is unrelated to this change.

References

Edited by Miguel Rincon

Merge request reports