**Motivation**
Our "dependency management" (more accurately, requiring js files/modules within other ones) of javascript files/modules are being currently handled through the Resource Loader.
Resource Loader dependency management feature was not design to also host this kind of use-case.
Using javascripts's require/import solution is more appropriate for that use-case. Using a packing solution on top of that is also appropriate to reduce the amount of http traffic overhead if we load these files asynchronously (which is still not supported by all browsers to this date https://caniuse.com/#feat=es6-module-dynamic-import) as well as
**Problem**
- Our frontend codebase in Wikibase Repo is pretty modular which is good but we are using RL for dependency management and class loading resulting to have 300 RL modules with a very complex dependency relationship that causes TTFB to be high and pretty big network overhead (e.g. {T203696}: "It looks like Wikibase is trying to use ResourceLoader as a class loader(!) which may be difficult to quickly re-architect, but any reduction would be worthwhile.")Testing modules and developing them is rather hard due to the deep integration with the Resource Loader.
- Testing modules and developing them is rather hard due to- Currently we can't use ES6 features in the deep integration with RLfront end code.
- RL's minification method is also a little bit outdated and inefficient (See {T49437}). Tools like Webpack solves or improves all of these issues.
**Other problems, partly related**
- Currently we can't use ES6Our frontend codebase in Wikibase Repo is pretty modular which is good but we are using RL for dependency management and class loading resulting to have 300 RL modules with a very complex dependency relationship that causes TTFB to be high and pretty big network overhead (e.g. {T203696}: "It looks like Wikibase is trying to use ResourceLoader as a class loader(!) which may be difficult to quickly re-architect, but any reduction would be worthwhile.").
**Suggested Solution**
UseTry usingse Webpack to bundle our javascript modules in single files.
Webpack is chosen for the following reasons:
- it is quite mature build and packing tool in javascript ecosystem
- We can combine RL modules- it brings modern tooling and reduce their number in Wikidata's production to decrease the traffic sent to users and TTFBfeatures from javascript ecosystem into our stack through easy integration with Babel
- It has better minification than RL.it has been already done and used in our production for MobileFrontend skin {T195475} {T207787} {T194098}, hence not completely unheard of in the Mediawiki context
- it brings modern tooling and features from javascript ecosystem into our stack through easy integr- It has better minification with Babelthan RL.
- it has been already done and used in our production for MobileFrontend skin {T195475} {T207787} {T194098}We can combine Resource Loader modules and reduce their number in Wikidata's production to decrease the traffic sent to users and TTFB
**Expected Impact**
- On dev productivity: can be big, allowing us to use modern javascript through Babel
- On performance (secondary goal here): Webpack is not the only mean to improve performance.
- Every module removed from lib or client will have ~30GB/day reduction on network. We planning to drop probably around 10-20 of them
- Every module removed from view or repo will have ~55 MB/day (wikidata) + 90 MB/day (commons) reduction on network. We are planning to drop probably around 100-200 of them.
- TTFB is hard to measure. Can be measured afterwards.
- The network reduction due to using webpack instead of RL manification is hard to measure. Can be measured afterwards.
**Estimated Trailblazing length**
couple of weeks (2-3 weeks for 100-150% FTE)