Page MenuHomePhabricator

Prepare case for RL/Webpack trailblazing
Closed, ResolvedPublic

Description

Preparing presentation of a case for trailblazing for https://phabricator.wikimedia.org/T228513

Nice questions

  • what the current problem(s) are ?
  • who/what is suffering from it ?
  • what kind of impact the solving of the issue will generate and why?
  • who and/or what will take advantage from it ?
  • how the solution a priori looks like and what it involves ?
  • is there anything you think we need to know or take into account before or while the implementation ?
  • what the requirements for the trailblazer team are, if any ?
  • is any previous knowledge of something specific desired or required ?
  • what the learning opportunities for the trailblazer team are?
  • is there anything that speaks against us the trailblazing happening? if so what and why?
  • any thing else you think is relevant for your case

Event Timeline

• alaa_wmde moved this task from Todo: Focus to Doing on the User-Alaa board.

what the current problem(s) are ?

problem one
we cannot use es5/6 features that are not supported by browsers yet and cannot be polyfilled in runtime (like URI api. ref: T117651: Align mediawiki.Uri more with the native URL constructor and <the one with browser.URI>)

probelm two
managing code dependencies between javascript modules/files is done away from the code (in extension.js or equivalent), by using RL dependencies mechanism, which seems not to be the right solution for all cases.

who/what is suffering from it ?

problem one

  • developers productivity not catching up with modern javascript, making it become slower with time as the projects expands.
  • on boarding young developers increase in cost too as they need to get to learn and work with semi-outdated and limitef APIs and standardbof JS.

problem two

  • developers productivity as the dependencies between code modules cannot be detexted easily, neither by eye nor by modern IDEs and tools.
  • users of all wikis around the globe where our wikibase client is loaded on that wiki. They are affected by the increased data traffic as well as tike-to-first-render due to the bigger http request/reaponse sizes.
  • servers that are processing those modupe names for the purppse of packaging final response. (need more detail here. this might prove even smaller footprint than the one before on one requedt, yhough it might have a similar effect of piling up esp. the more modules we add.. the correlation seems nonlinear too)

what kind of impact the solving of the issue will generate and why?

probelm one
Using webpack will enable developers to:

  • manage their code dependencies between modules using require and/or import, allowing better navigation and resolution for tools, easier reasoning about the code for developers, less fragmented changes when modifying dependencies of one file/module, and using standards of managing javascript modules for exporting stable interfaces.
  • use es5/6 features, esp. things that cannot be pulyfilled in runtime, through webpacks mainstream integration with babel project.

probelm two
Using webpack will:

  • decrease the overhead on http tequest/response sizes as it will pack final modules with their dependencies in one file that is referenced in RL (without referencing those dependencies in RL anymore, thus reducinf the number of modules for RL to request and process).
  • will probably decrease file sizes transferred to the client too, as webpacks minification is far more advanced than RL one.
  • reduce maintenance cost of improving and adding new features to RL as moving to webpack ecoaystwm we get manybof those with kuchlower costa of integration and low-cost of development/maintenance, plus that any cost we put to fix a bug or develop a features goes back to the whole javascript community ;)

who and/or what will take advantage from it ?

The obvious advantage will probably be for developers who will be able to use modern features of ES5/6, and configure their IDEs to support them while working on js modules. That is expected to increase their productivity, probably significantly.

how the solution a priori looks like and what it involves ?

The solution will probably involve using something other that RL dependency mechanism to manage our internal (private) dependencies to modules that we create for the sake of modularity and maintainability.
The solution may as well provide an easier way to use or polyfill es5/6 features.

The current suggested solution is to use Webpack to pack our external modules that need to be shipped to the client, without exposing internal "modules" as RL modules, as well as bringing easier polyfilling through integration with babel-core and presets.

Webpack solution involves:

  • learning webpack
  • figuring out which of our modules are external to be loaded through RL
  • those external modules will need to be then defined as webpack packs and (most likely) be built at dev machines and pushed into the repository in the first iteration
  • all other internal modules are then dropped from RL dependencies definitions, and instead imported through require/import inside the files that need them
  • checking if any caching related logic need to be updated

Some more technical details can be found in T228513: Start using webpack for dependency management and bundling