**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.
Allegedly,Resource Loader dependency management feature was not design to also host this kind of use-case. 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 makes it extremely heavy (300is 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. 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, Also we need to conform to ES5.but any reduction would be worthwhile.").
- Testing modules and developing them is rather hard due to the deep integration with RL.
- RL's minification method is also a little bit outdated and inefficient (See {T49437}). Webpack solves or improves all of these issues.
- Currently we can't use ES6.
**Suggested Solution**
Use 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 and reduce their number in Wikidata's production to decrease the traffic sent to users and TTFB
- It has better minification than RL.
- it brings modern tooling and features from javascript ecosystem into our stack through easy integration with Babel
- it has been already done and used in our production for MobileFrontend skin {T195475} {T207787} {T194098}
**Impact**
- On performance:dev productivity: can be big, allowing us to use modern javascript through Babel
- On performance: These are not tightly related to webpack and we should do it regardless of webpack but this can also be achieved using webpack.
- 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.
- On dev productivity: can be big, allowing us to use modern javascript through Babel
**Estimated Trailblazing length**
couple of weeks (2-3 weeks for 100-150% FTE)