There are [[ https://www.mediawiki.org/wiki/Vue.js#Two_ways_to_parse_Vue.js_templates | two ways to process Vue.js templates ]] in MediaWiki: a build step and on-the-fly compilation. Which should we we use for this project? That's what this task decides.
== Acceptance criteria
- [] A decision to use a build step, on-the-fly compilation, or both is made.
- [] At least one new task is created to implement the choice(s).
== Build step
The most performant, flexible, and least risky option, but more upfront work:
- Clumsy asset versioning. Plain and simple: we know this song and dance well but it is a friction until [[ https://phabricator.wikimedia.org/T199004 | the build step RFC ]] is complete. More specifically, most JavaScript patches will create merge conflicts, we have to make another copy of our dist test script, and our Git history is polluted with build products. This friction hurts newcomers especially.
- The most performant byte sizes and rendering. This derisks a major concern for the project as much as possible.
- Requires extra configuration. Web has the experience (e.g., [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Popups/+/a63a1cf/webpack.config.js | Popups ]], [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/01d3f48/webpack.config.js | MobileFrontend ]], and [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/ea2bcd4/.storybook/webpack.config.js | Vector Storybook ]]) to define good patterns for the broader organization but this is extra work. Sharing that configuration requires further additional work but may allow some commonization of Web's existing six Webpack configs.
- Immense flexibility to leverage any tool in the JavaScript ecosystem. A build step, formal or otherwise, enables an extraordinarily useful abstraction between the code written by developers and the bytes shipped to users. A build step is a gateway to the entire wealth of tooling in the JavaScript ecosystem second only to `package.json` itself.
- Requires additional consideration for sharing dependencies across projects (e.g., runtimes).
- There are no limitations on the Vue.js code written. That is, all source will be canonical Vue.js, not MediaWiki-specific Vue.js. This meets the expectations of newcomers and developers interested in using our components in non-MediaWiki contexts.
- Developer productivity boost via hot module replacement functionality. In @santhosh's words, "Cannot even compare it with the debug=true mode of development speed :-)"
- If only a build step is used, no feedback is provided on the on-the-compilation implementation.
== On-the-fly compilation
Less performant and inflexible, but very little upfront work:
- Minimal configuration. Build step tooling is always a pain to configure properly but on-the-fly supports very little configuration.
- Less maintenance. Build-step specific tooling requires periodic upgrades. On-the-fly compilation is part of Core.
- All code written is most likely to work in any MediaWiki context but less likely to work in non-MediaWiki contexts.
- This workflow is supported by at least two Foundation developers and may be the mechanism used by gadgets and tools unable to use a build step.
- [[ https://vue-loader.vuejs.org/guide/scoped-css.html | Scoped styles ]] are unsupported.
- What you write is what you ship--No ES6, TypeScript, or language compilation support. At time of writing, this means ES5 only.
- [[ https://vuejs.org/v2/guide/syntax.html#Shorthands | Vue.js directive shorthands ]] are unsupported `@` for `v-on` and `:` for `v-bind`.
- The version of Less used must match MediaWiki's version (very old). However, everything that works in normal MediaWiki styles works here (e.g., [[ https://www.mediawiki.org/wiki/CSSJanus | CSSJanus ]], relative URLs, imports, etc).
- Possibly the standard MediaWiki way to build Vue.js apps but definitely the nonstandard rest-of-the-world way.
- Additional limitations for on-the-fly compilation may be uncovered during development. On one hand, that's exactly the kind of thing FAWG should know about sooner rather than later. On the other, that hurts product development. The build step RFC isn't even done yet but //local// build steps have historically had excellent production success.
- If only on-the-fly compilation is used, no feedback is provided on the build step implementation.