Page MenuHomePhabricator

Consider migrating from Vuex 4 to Pinia
Open, LowPublic

Description

Background

Pinia is the successor to Vuex. It promises to be lighter weight than Vuex (6KB for Pinia 2.0.13, 15KB for Vuex 4.0.2) and to support TypeScript better.

We could not immediately replace Vuex 4 with Pinia, because Pinia isn't fully backwards compatible with Vuex 4. The APIs are reasonably similar, but there are big enough differences that it would be difficult to write compatibility wrappers that would allow code expecting Vuex 4 to run on Pinia. Instead, we would use Vuex 4 and Pinia side by side for a while, with new code using Pinia, and old code being migrated from Vuex 4 to Pinia over time. This theoretically means that both libraries could be loaded on the same page, which would be (slightly) wasteful; but I don't think that it'll happen much in practice, because the features that currently use Vuex tend to be ones that take over the entire page.

To install Pinia in MediaWiki, we would probably want to use pinia.iife.prod.js / pinia.iife.js and wrap them so that VueDemi is aliased to require( 'vue' ). Alternatively, we could use pinia.prod.cjs, but then we would have to set up a module alias for vue-demi to redirect to vue, and we would have to make @vue/devtools-api available (in the iife versions, that package is inlined).

Pending security review

T308495: Application Security Review Request : Pinia

Event Timeline

Migrating existing projects that use Vuex 4 to Pinia might be low priority, but new projects built in Vue 3 that require a state management library should probably use Pinia. Should we open a separate task for this, mostly to make sure we can get a timely security review of Pinia if we decide to use it (which seems likely)?

Migrating existing projects that use Vuex 4 to Pinia might be low priority, but new projects built in Vue 3 that require a state management library should probably use Pinia. Should we open a separate task for this, mostly to make sure we can get a timely security review of Pinia if we decide to use it (which seems likely)?

For what it’s worth, in Special:NewLexeme revival we were planning to use Pinia until we realized it hadn’t been security-reviewed yet and sticking to Vuex would be the easier option for the time being :) so thumbs up from our side.

Thanks for that context, @Lucas_Werkmeister_WMDE—I went ahead and submitted a security review request for Pinia, since we'd like to make sure teams using Vue 3 can use Pinia as soon as possible. Is this a foregone conclusion for Special:NewLexeme revival, or would you still consider using Pinia if it worked with your timeline?

We’re writing our code using Vuex at the moment (current src/store), but I think it wouldn’t be too much work to migrate to Pinia (most of our development time so far has gone into code outside the store, I’d say).

The main challenge we'd have to address in order to use Pinia is that Pinia is mostly compatible with Vuex 4, but not entirely. The API for creating a store is different (we could probably add a compatibility wrapper for this), and mutations don't exist in Pinia. Modifying code written for Vuex 4 such that it would work with both Vuex 4 and Pinia, or adding compatibility wrappers so that Vuex 4 code works with Pinia (which would be required for a smooth migration from Vuex to Pinia) may or may not be easy.

Alternatively, we could not pursue a backwards-compatible replacement of Vuex 4 with Pinia, and instead use Vuex 4 and Pinia in parallel. Code using Vuex 4 could migrate to Pinia over time. Having two different versions of what's more or less the same library is not great, but probably not very wasteful performance-wise either: it's not very likely that Vuex and Pinia would be loaded on the same page, because it's uncommon for multiple applications that are complex enough to need a store to both appear on the same page (stores are mostly used in dedicated page applications, like special pages).

Alternatively, we could not pursue a backwards-compatible replacement of Vuex 4 with Pinia, and instead use Vuex 4 and Pinia in parallel. Code using Vuex 4 could migrate to Pinia over time. Having two different versions of what's more or less the same library is not great, but probably not very wasteful performance-wise either: it's not very likely that Vuex and Pinia would be loaded on the same page, because it's uncommon for multiple applications that are complex enough to need a store to both appear on the same page (stores are mostly used in dedicated page applications, like special pages).

This seems a good option because it's flexible. In the context of T297763: Migration of Mentor dashboard modules to Vue the Growth-Team has used Vuex 4, see gerrit 778997 . We still haven't figured out which specific benefits would using Pinia bring to our current state management code and we would be sticking to Vuex for sometime if we can. Could we document somewhere which Vue-related packages will be "LTS" modules in ResourceLoader? I added a tiny note in the Module_definition_example section with a link to the vue/vuex versions but maybe it belongs elsewhere.