See T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later for ES6 support (works, sort of) and T56864: ResourceLoader: Implement support for LESS in wiki modules (user and site), supporting e.g. MediaWiki:Common.less for LESS support (pretty far away I think).

T155567: Make OOUI easier to use for gadgets is an old task about a declarative syntax for simple widgets that might be relevant.

• Hard-coded file extensions

There are – rEGAD includes/MediaWikiGadgetsDefinitionRepo.php:272-282 (at 7793a9475f18) silently drops everything that doesn’t end in .js, .css or .json while it classifies pages. The classification is used in rEGAD includes/GadgetResourceLoaderModule.php:46-69 (at 7793a9475f18) – if setting ['type' => 'script'] is appropriate for .vue files, enabling Vue is as easy as changing the regex in MediaWikiGadgetsDefinitionRepo.php (which doesn’t necessarily mean that Vue actually works, just that the file extension barrier is removed).

In T330349#8641092, @Tacsipacsi wrote:

if setting ['type' => 'script'] is appropriate for .vue files, enabling Vue is as easy as changing the regex in MediaWikiGadgetsDefinitionRepo.php (which doesn’t necessarily mean that Vue actually works, just that the file extension barrier is removed).

['type' => 'script'] is not the appropriate type for .vue files, it's ['type' => 'script-vue'] (this matters because .vue files need certain transformations, and can also contain styles in addition to script code). But that shouldn't be too hard to address, we'd probably just need to add another category of resources to the Gadget class, like we did for JSON files ('datas' at rEGAD includes/MediaWikiGadgetsDefinitionRepo.php:272-282 (at 7793a9475f18) and getJSONs() at rEGAD includes/Gadget.php:334 (at 7793a9475f18))

There's also the question of what content model would the on-wiki vue pages take? Can they be JavaScriptContent, or do we need a new content model? For ES6 gadgets, no syntax checking is done (because the syntax validator only supports ES5 as of now), so it would technically be possible to use the JS content model, but that is a bad idea. If we were to make a new content model, should that go into MW core, or in the Gadgets extension?

In T330349#8643318, @SD0001 wrote:

If we were to make a new content model, should that go into MW core, or in the Gadgets extension?

I’d say core. Vue is supported by core, and maybe one day user Vue subpages will also be a thing, along with user JS and user CSS pages, which are supported by core.

Change 907556 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] [WIP] Support loading .vue pages in the MediaWiki namespace

https://gerrit.wikimedia.org/r/907556

Change 907557 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/extensions/Gadgets@master] [WIP] Support .vue files in packaged gadgets

https://gerrit.wikimedia.org/r/907557

The attached patches are a proof of concept of what it would take to support .vue files in Gadgets. Most of the changes are in core:

• Add a content class, content handler and content format for .vue pages
• Add special treatment for Vue pages in all the places where we have special treatment for JS pages
• Add support for .vue files to WikiModule
  • This requires duplicating all the Vue handling code from FileModule. This should be refactored to move more of this code into Module where both FileModule and WikiModule can use it, but that's nontrivial because FileModule supports Less compilation whereas WikiModule does not (which appears to be somewhat deliberate, per T56864#6153179)
  • Making Less compilation for styles inside Vue files (or styles on wiki pages generally) doesn't seem like it would be hard, but we'd need to decide whether this is desirable, per T56864#6153179

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/9e708d7417/w

@Catrope when you're back, can you file a follow-up task describing the work you summarized above (plus any other info that may be helpful for whenever we pick this up in the future)? Then I think we can close this spike.

@egardner @Catrope did we ever create that follow up task? Wondering if this can be closed.

In T330349#8955965, @CCiufo-WMF wrote:

@egardner @Catrope did we ever create that follow up task? Wondering if this can be closed.

No, we did not, I was supposed to do it on Friday but I got distracted. I will prioritize doing this on Monday.