Hey @Catrope, if you were starting a new MW extension using Vuejs in the next week or two, would you

1. use Vue 2 and migrate it to Vue 3 later or
2. start with Vue 3 by including a private copy and use the official version later or
3. something else

The extension won't be deployed anywhere for several months. The whole team is new to Vue so it would feel wasteful to learn a style and quickly migrate to a different style (of there are significant differences between v2 and v3, that it).

thanks!

In T289017#7309788, @SBisson wrote:

Hey @Catrope, if you were starting a new MW extension using Vuejs in the next week or two, would you

1. use Vue 2 and migrate it to Vue 3 later or
2. start with Vue 3 by including a private copy and use the official version later or
3. something else

Apologies for the late response, I started my vacation the day after you posted your comment.

I will ask the other engineers on the Design Systems Team to weigh in too (cc @egardner , @AnneT), but my recommendation would be #1. Use the Vue copy in MW core, and upgrade along with it.

The extension won't be deployed anywhere for several months. The whole team is new to Vue so it would feel wasteful to learn a style and quickly migrate to a different style (of there are significant differences between v2 and v3, that it).

The biggest difference between v2 and v3 that affects how you write code and how you think about things is the composition API, but we have already installed a plugin for v2 that provides that API, and some of our existing code written for v2 already uses it. The remaining differences between v2 and v3 are relatively minor. There are some other nice features that v3 adds, and there are some breaking changes that make upgrading harder (most which are papered over by Vue's migration build), but they're mostly things that you wouldn't encounter very often and that don't affect the way that you would architect or think about things. An example that I think is pretty representative is that the behavior of <div :some-attribute="foo"> changed in the case where foo is false (from dropping the attribute to setting it to the string "false"). For a list of new features and breaking changes see this page in the migration guide.

Overall, most code written for Vue 2 (especially user interface code that is just programming an application rather than providing a library) works in Vue 3 with minor modifications, and works with the compat build of Vue 3 with no or minimal modifications in most cases; see T289019 for our adventures in validating this and finding edge cases. In some cases you may write something differently for Vue 2 than you would for Vue 3, but I think those cases are pretty limited and specialized; the ones I can think of are the teleport feature and the ability to use Vue-native two-way bindings (v-model) for multiple props in the same component. If you start your project with Vue 2 and then keep a running list of things you'll make nicer once you have Vue 3, I think that list will not be empty but will be fairly short.

We're hoping to upgrade to Vue 3 (with compatibility) in MW core soon, so hopefully this issue will be moot anyway. The main blockers are the security review (T257734) which is estimated to be completed by the end of September, and unbreaking the extension breakages in T289019. If that goes well we could have Vue 3 available in 3-4 weeks, but we haven't tried running it against Wikidata yet, so we'll see.

I agree that Vue 2 is safest for now, and that migration to Vue 3 shouldn't be very time-consuming or difficult, especially with the compatibility build.

To expand a bit on the Composition API: Vue 2 components use the Options API, which is still available in Vue 3, but you can also start using Vue 3' Composition API via the Composition API plugin. You can check out how we're using it in a few WVUI components (Checkbox, Dropdown, and Radio - all the others exclusively use the Options API).

When starting out with Vue I found the Options API to be very straightforward to learn, so if you want to keep your first Vue project simple you could stick with it. However, the Composition API offers some benefits (better code organization and sharing, for example) and you'll also get a chance to learn Vue 3's new reactivity system, which offers more granular control of reactivity than the previous version.

Adding Design-Systems-Team because Design-Systems-team-20200324-20220422 got archived though this open task has no other active project tags associated, so it cannot be found on boards.

Thank you for catching this, @Aklapper !

This task is in progress again, but we can consider it "blocked" until T289020: Migrate all extension/skin code to Vue 3 is complete.

I did a quick search for Vue.configureCompat calls across our codebases. Unlike some of the other compat code artifacts, this line will cause JS to error out once we remove the migration build, since that method will no longer exist on the Vue object. We will need to ensure all traces of this are removed from any code that is still in production before we flip the switch.

Here are the places that still include this code as of Tuesday Nov 28:

• The Extension:VueTest (this is a legacy example repo maintained by DST; we've talked about replacing this with the more modern CodexExample; perhaps it's time to archive this repo?) – this is not deployed in production anywhere
• Extension:MachineVision – this has also been officially un-deployed, right?
• Extension:FileImporter – who maintains this?
• CodexExample Extension – this lives in GitLab and is not picked up by CodeSearch. I will update this shortly.

egardner opened https://gitlab.wikimedia.org/repos/design-systems/CodexExample/-/merge_requests/9

Remove Vue.configureCompat call

All of these configureCompat calls have already been wrapped in if statements, so they should be safe. See e.g. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VueTest/+/968789 . We should remove these after the migration is complete, but for now I think it makes the most sense to keep them as conditional calls.

catrope merged https://gitlab.wikimedia.org/repos/design-systems/CodexExample/-/merge_requests/9

Remove Vue.configureCompat call