User:Roan Kattouw (WMF)/Build steps

Proposal
In the shared component library repo, I'm OK with using a build step, because we'll basically treat it as a third-party library from MediaWiki's perspective: the library periodically publishes a release, and we put the build products from the latest release in  in MediaWiki. OOUI also works that way, and also uses a build step. To address security and reviewability concerns, we could explore ways to set it up to produce output that is somewhat reviewable (e.g. minified but not uglified JS). We wouldn't have to look at the build output changes for every commit, only for every release.

Shared components typically have complex implementations, while "end user components" are typically simpler. Shared components also tend to have more complex relationships with each other, and the component library will likely need to generate multiple bundles with different combinations of components. These are all reasons why a build step is more useful here.

In MediaWiki core and extension repos, I think we should not use a build step, at least for now. End user components are simpler than shared components, and the bundling needs for them are closer to what ResourceLoader provides than to what a build step would provide. See also this longer explanation for why build steps that perform bundling and tree shaking aren't as well suited to MW extensions.

The main thing that RL doesn't provide that we would like to have for end user components is ES6 support. Writing Vue components in ES5 is a little annoying, but workable (as we know from Anne and Eric's MachineVision port), and not more so than having to write any other JS code in ES5. So I think this is a reason to look at how we can support ES6 MW-wide, not a reason to introduce a build step specifically for Vue code.

Pros and cons
Pros:


 * Support for ES6, Typescript etc in the component library, where the most complex code lives
 * Complexity of maintaining and running the build step is "hidden away" in the component library
 * Development in MW core and extensions follows existing patterns

Cons:


 * Need to write ES5 in MW core and extensions
 * Need to use client-side template parsing for components from MW core and extensions (that don't come from the shared library)

Meta
I don't understand why we're in a rush to decide this. It doesn't block the Vue project or the desktop refresh project, and in any case, the Vue project shouldn't be rushed and shouldn't be blocking anything that's urgent. We also have a workable alternative to a build step; people might not like it as much, but replacing it isn't urgent. Any decision to use a build step in MW core or extension repos will also need to involve people from Technology (at minimum, Release Engineering), it's not a decision that Product can make on its own.