Mark Florian (8ceadda2) at 17 Mar 17:19

Mark Florian (4b0cb34d) at 17 Mar 17:19

... and 1 more commit

What does this MR do?

Don't run ui:duo_job in fork MR pipelines.

This is because the needed CI token is only present in pipelines of the canonical project.

The job will run when a new pipeline is created in the fork MR by a member of the canonical project.

Screenshots or screen recordings

Integrations

• GitLab: mr_url
• CustomersDot: mr_url
• Duo UI: mr_url
• Status Page: mr_url
• Docs: mr_url
• Switchboard: mr_url

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Thanks @thutterer. I haven't given this a thorough review, as I'm suffering from AI generated code review fatigue 😩 But, the general approach seems about right.

A few notable things I have not done:

• Run the GDK locally with this (i.e., spun up the integration branch).
• Checked it under ?vue3 applications.
• Looked at the API surface to ensure it's the same. (One thing that comes to mind is the title option taking vnodes - I vaguely recall something in the monolith does that, or something like it).

Anyway, I've left a few comments. Back to you 🏓

Thanks @xanf! I've given this a spin, and I think it works well 👍

• Vite still works.
• I tried ?vue3 on Security Configuration and Work Items, and both seemed to work, apart from a minor attribute fall-through issue I saw on the former.
• Webpack still works.

Do you think this needs another reviewer's eyes, or is it sufficiently low risk? Either way, approving.

Great work 👏

What does this MR do and why?

Introduces a Vite plugin that enables per-entrypoint iterative Vue 3 migration. By appending ?vue3 to a JS import specifier, the entire dependency subtree becomes "infected" — Vue ecosystem packages (vue, vuex, vue-router, vue-apollo, etc.) are redirected to their Vue 3 compat wrappers, while non-Vue imports get separate module instances to ensure isolation.

This allows migrating individual page entrypoints to Vue 3 one at a time without changing the global VUE_VERSION environment variable, enabling gradual adoption.

How to set up and validate locally

1. Ensure you have a working GDK with Vite enabled
2. Add ?vue3 to any JS entrypoint import, e.g.:

   import initFeature from 'ee/some_feature/bundle?vue3';

3. Run gdk start and navigate to the page using that entrypoint
4. Open browser DevTools Network tab — infected modules should have ?vue3= in their URLs
5. Vue ecosystem imports (vue, vuex, etc.) should resolve to vue3compat/ wrappers

Known issues:

• vite production build (will be addressed in follow-up MR)
• this is as dumb as possible - it will duplicate every possible module it discovers. this is intentional
• HMR. It might or might not work 🌚

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.

It worked 🤷

Ooooh. I just realised I've been running with vite.vue_version = 3 in my gdk.yml. That must have been there for ages!

Which is kind of cool... It means I've been running the GDK under Vue 3 for perhaps weeks without realising 😆

@xanf Aha! Could it be this, from gdk tail vite?

✘ [ERROR] Could not resolve "~/vue_shared/translate"

    app/assets/javascripts/lib/utils/vue3compat/vue.js:6:22:
      6 │ import Translate from '~/vue_shared/translate';
        ╵                       ~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "~/vue_shared/translate" as external to exclude it from the bundle, which will remove this error and leave the unresolved path in the bundle.

Also related, from Slack:

Seems like in app/assets/javascripts/lib/utils/vue3compat/vue.js we are using an alias to get the logger and when Vite tries to resolve imports within that file, the ~ alias hasn't been set up yet in the Vite config.

I'm once again having a lot of trouble running this branch 🤔

@danmh Maybe? I've pushed a change that removes things that might help, but given I couldn't repro this locally, who knows.

Mark Florian (3f43123c) at 17 Mar 14:20

I literally cannot reproduce this. I hate Storybook.

How on earth is the Vue 3 version failing this way...?

Mark Florian (a5c8bf20) at 17 Mar 14:06

note: I don't think that ::Pajamas::AlertComponent needs similar treatment, since those are server rendered, and therefore visible on page load. For those, I don't think there's a good reason to be able to programmatically focus them. We shouldn't be messing with initial focus on page load (maybe?).

TODO

@trevorpierce Would you review this from an accessibility perspective, please?

@thutterer Would you review the frontend changes, please?

@danmh Would you review the new screenshot test/visual changes, please?

Mark Florian (819e1694) at 17 Mar 13:04

Mark Florian (ebb0a8c9) at 17 Mar 12:42