The Inuka-Team needs this for Wikistories

We'll include our own copy in the short term, like WikiLambda is doing.

I found this task, since I was also looking for a router to use in my code.

To my surprise, ContentTranslation seems to be the only remaining user of Vue Router in production. Both WikiLambda and Wikistories have dropped their use of Vue Router (in T301520 and T313839), replacing them with very simple custom implementations (~200 lines for WikiLambda, and ~60 lines for Wikistories, and in both cases that includes the route definitions).

Would it be correct to think that Vue Router is no longer the obvious choice, and writing the code ourselves is preferable for many applications?

I guess Vue Router may be too big of a dependency. Maybe if we were building the whole website as a Vue app, it would be worth it, but as it stands MediaWiki itself handles most of the routing. It also became easier to implement client-side routing using HTML5 History API as we dropped support for older browsers.

In T290916#8939684, @matmarex wrote:

Would it be correct to think that Vue Router is no longer the obvious choice, and writing the code ourselves is preferable for many applications?

I guess Vue Router may be too big of a dependency. Maybe if we were building the whole website as a Vue app, it would be worth it, but as it stands MediaWiki itself handles most of the routing. It also became easier to implement client-side routing using HTML5 History API as we dropped support for older browsers.

I think Vue Router is still widely used in the larger Vue community, but it will probably see limited use here for exactly the reason you mention. A client-side router is the definitive SPA feature in my opinion, whereas MW is very much a multi-page app. For more complicated dashboard or "wizard" features with multi-step flows it may make sense (and I'm okay with making it available as part of MW if folks need it) but for most other on-wiki features it's probably overkill.

Sometimes I do wonder if there would ever be interest in a rich, SPA-style MW skin – such a skin could use Vue-router to make API requests for subsequent navigation after server rendering the initial page, etc. But I don't think anyone is planning to build such a thing any time soon...

Content Translation is essentially an SPA (it uses its own internal hidden skin under the hood) so its usage makes sense in this context.

The state of need may have changed over time and I have been having recent discussions with engineers from Moderator-Tools-Team about how handy would come to have vue router available in core for the development of Extension:PersonalDashboard. Also in recent design explorations by the Growth-Team we're hitting the "wizard" features with multi-step flows that @egardner is mentioning, for example in T425768: [Spike] WelcomeSurvey redesign exploration. So the current status quo is there are already 2 extensions using it, (Extension:DonationInterface, Extension:ContentTranslation as mentioned by Jdlrobson). And two potential adopters: GrowthExperiments & PersonalDashboard.

Is this enough to re-evaluate the suitability of accommodating vue-router as a core module? Or if the package is deemed overkill, propose and discuss alternatives.

Yes, as mentioned, we plan to add this directly to the PersonalDashboard extension if it won't be provided by core. We want to be able to hand off subroutes to contributed vue modules in the dashboard in addition to providing really clear convention for query param handling. We would like to make it as easy as possible for folks familar with vue to become technical contributors to the dashboard.