Build step

more history of solving these sorts of problems using ResourceLoader directly.
 * Ahead-of-time compilation has historically not had much continuous integration support at Wikimedia. These processes are being evolved using containerization and PipelineLib. In the interim, asset versioning is clumsy. Repos require extra tooling, most JavaScript patches will create merge conflicts, and Git history is polluted with build products. This friction hurts newcomers especially.
 * Build steps at MediaWiki often rely on JavaScript tooling which have notoriously large dependency trees. However, most are limited to development-only dependencies as opposed to runtime dependencies.

Benefits

 * The status quo. High cohesion with the current MediaWiki ecosystem which has strong patterns for internationalization.
 * Required when key parameters vary and cannot be known ahead-of-time.
 * Centralized build step in Core. All changes made apply to all projects.

Limitations

 * Every just-in-time build step must be extremely performant, so fast that it can run on-the-fly, or pages will load slowly. Additionally, sequential steps cannot be appended ad infinitum.
 * Effectively, ResourceLoader's just-in-time build steps can only use tools written in PHP. JavaScript execution is not possible. For practical purposes, this means the only tools used at MediaWiki are built by Wikimedia or adopted abandonware which greatly impedes evolution and has a significantly negative impact on the development culture.
 * Just-in-time build steps are less secure. They execute on production servers and serve content directly to the user. This eliminates the separation between development and runtime-only dependency trees, which can dramatically increase the attack surface, sometimes by orders of magnitude. Additionally, build outputs are shipped directly to the user without any opportunity for security review. When it comes to security, a just-in-time build step always strives to be as secure as an ahead-of-time build step that produces static outputs.
 * Just-in-time build steps are custom and complex. An ahead-of-time build step can easily be a one-liner that invokes standard tooling but the equivalent just-in-time build step, if one exists, is just as likely to be hundreds of lines of custom code. Historically, these custom steps have suffered from bus factor and received little attention beyond basic life support. Few engineers possess the abilities to write code of the caliber needed to add new build steps or change existing ones, which means the rest of Wikipedia and WMDE is blocked on their evolution. For example, we have been unable to keep pace with fundamental features like source map support (a formal request since 2013) or ES6 transpilation. In fact, there are laundry lists of missing features now standard elsewhere. The lack of standard functionality means that developing any code at Wikimedia is a completely different and far slower experience than the rest of the industry.
 * Just-in-time build step outputs have worse caching. The most advanced build step executed at runtime endeavors to have the same caching that comes out-of-the-box with an ahead-of-time build step: a plain file on disk.
 * Code reuse and librarization and integration requires significant work.
 * What you write is what you ship. No ES6, TypeScript, or language compilation support. At time of writing, this means ES5 only.
 * The version of Less used must match MediaWiki's version (very old).
 * Non-standard.
 * SVGs must be committed minified or delivered to the client in "debug mode."
 * Very primitive debug and development capabilities. No hot module replacement, automated chunk splitting, or tree-shaking, for example.
 * ResourceLoader's just-in-time build step is unavailable for certain projects such as the Page Content Service and libraries.
 * No clear scope or path forward for present and future needs.

Business and use cases
See the platform evolution section of the annual plan, ahead-of-time build steps are necessary in conjunction with just-in-time build steps to achieve the following outcomes:


 * "The ability to build modern experiences" was no better demonstrated than by the new ContentTranslation app which was developed using Vue CLI (a Webpack wrapper) and generated using an ahead-of-time build step.
 * Supporting efficient and effective Wikibase development is also identified. WMDE's Wikibase is a well-known user of ahead-of-time build steps in multiple projects.
 * Infrastructure to serve "with high performance" demands the best profiling and optimization tooling available, not ancient tools that can only run on-the-fly.
 * Significantly "improving engineering productivity" requires bold changes to how we develop. Not small, back-dated improvements like adding source map support but modern development tooling.
 * All bullets under outcome #2, "Fully automated and continuous code health and deployment infrastructure," and outcome #3 "Tooling for contributors is easy to use, well-documented, and accessible to users, increasing engagement and contribution."

Notable projects using an ahead-of-time build step
Ahead-of-time build steps are everywhere in Gruntfiles, Gulpfiles, Webpack configs, NPM package.json files, and shell scripts.
 * OOUI: Portions of this library are built with Grunt and a suite of packages from NPM for minification, uglification, and additional processing. The results are dozens of build products that are file-copied into Core manually.
 * Page Previews: All JavaScript sources are transpiled from ES6+ to ES5 with a Webpack-powered ahead-of-time build step.
 * Wikibase : Ahead-of-time build tools are used by Wikibase including Webpack, TypeScript, and a plethora of other standards to serve the Wikidata communities.
 * MultimediaViewer: Ahead-of-time build steps replace any human readable source SVGs with optimized, machine-readable outputs.
 * MediaWiki: Core uses an ahead-of-time build step on every deployment in a process called "a full scap."
 * MobileFrontend: All JavaScript is built by Webpack using an ahead-of-time build step.
 * Wikipedia for KaiOS: uses Webpack using an ahead-of-time build step.
 * ContentTranslation: a fully modern Vue.js interface using Vue CLI and standard tooling executed by an ahead-of-time build step.
 * Wikipedia.org: synchronizing sister project statistics.
 * VisualEditor: demos are built using an ahead-of-time build step.