Internally, ResourceLoader takes the data for module dependencies, and replaces the names of these modules with a number that is their index in the array of all modules in the registry that is sent to the client. This makes it harder to try and see which modules are depended on by what, and the only benefit is the reduction of the registry size, which generally isn't a concern in debug mode.
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| ResourceLoader: don't used indexed dependencies in debug mode | mediawiki/core | master | +15 -12 |
Related Objects
Related Objects
- Mentioned Here
- T85805: Introduce ResourceLoader debug mode v2
Event Timeline
Comment Actions
Change 723645 had a related patch set uploaded (by DannyS712; author: DannyS712):
[mediawiki/core@master] ResourceLoader: don't used indexed dependencies in debug mode
Comment Actions
This makes it harder to try and see which modules are depended on by what […]
The output of modules=startup is not aimed at developers writing frontend code and is not a public API. To see what a module depends on, visit its definition in code (usually extension.json), or retreive it from the browser console via mw.loader.moduleRegistry. These are easier to use, easier to to find, and I think we should improve developer experience there, not in some internal transfer mechanism.
The exception is of course for the handful of people working on the internals of mw.loader itself. In that case, this would go contrary to the direction set forth by T85805, which aims to reduce differences between production and debug mode, so that we may have confidence in debug mode being representative of production behaviour, and fully covering all the same code paths. Introducing branches like this means there would be a doubling (+100% increase) in all possible ways the code can behave in practice.
For anyone working on mw.loader itself, you'd presumably want it to behave the same way as production so that it can be debugged. To anyone else, why bother inspecting the lower level network response?
Comment Actions
The only difference is that we don't replace module names with numbers, which makes it easier to debug the logic for removing direct dependencies that are also indirect dependencies. extension.json specifies all dependencies, but the startup registry only includes some of those, and its not as easy to see which
Comment Actions
The dependency shake optimization should be of no interest to 99% of developers. Why does this matter?
If and when it becomes relevant, then you'd likely be someone working on RL in response to a bug report, and thus want to debug this very thing. I don't think we should change this, but I'm happy to explain further why, or to hear new use cases for which we should not apply it. We can think of other ways to accomodate the use case.
I'm closing this in response to the proposed solution, but am in no way declining any particular use case or need.
Comment Actions
Change 723645 abandoned by DannyS712:
[mediawiki/core@master] ResourceLoader: don't used indexed dependencies in debug mode
Reason:
per task