TLDR: Any ResourceLoader module will now run on mobile or desktop site by
default. Previously they would only load on the desktop site.
Hopefully this goes without disruption, but to be safe, if you maintain
code used in Wikimedia production, please:
1) check your experiences over the course of this week in mobile/desktop
site for JS errors/obvious UI errors (the former will be detected and
monitored via logstash)
2) check that your repository doesn't fail the core
testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
following Phabricator tickets to see if you are impacted on the long term
[4][5].
# Background
Back in the early days of MobileFrontend, most of the JavaScript we had was
not mobile friendly. To avoid this we created an allow-list system, where
JavaScript was disabled by default and extensions/skins had to explicitly
enable it by adding a "targets" property to their ResourceLoaderModule
definition.
This was meant as a short term solution, but as with many things, attention
got pulled elsewhere, and almost ten years later it was still there.
There have been many complaints about this over those years. Mainly:
1) It means we have split the ResourceLoader cache further
2) It's not intuitive - new code was getting shipped to desktop only
experiences by default.
It also featured on the Developer Wishlist of 2017 at #34 [1].
3) Many older features don't work for community members for no credible
reason.
# Recent developments
As one of the few remaining people responsible for doing this in the first
time, I felt obliged to spend some time over December trying to pay off
this technical debt. I audited code that was being removed by the targets
system [2] and made the target explicit. Where modules were problematic on
mobile, we marked them in such a way that it was clear that they should
only run in a certain mode. This was only possible thanks to attention from
Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.
Today, Roan merged a change that makes ResourceLoader modules default to
the desktop AND mobile sites. This should be a harmless change, but may be
unintentionally triggering failures in testUnsatisfiableDependencies tests
as it seems some extension/skins are not included in the MediaWiki core
PHPUnit test run. If you encounter this issue, the fix is relatively simple
- you must define targets explicitly (see this example [6] and apologies in
advance for any annoyance this may cause)
# For action
Please take extra care with your code that you test on both mobile/desktop
sites and at mobile/desktop breakpoints. It's still possible to ship code
to mobile/desktop and see these guidelines [3] if you need to do that or
reply to this email with any questions you have.
# Next steps
This change will help with limiting the targets system to existing known
cases. This has been a long term request of the performance team. Please
see the follow up tickets to see if there is any action from you at your
leisure [4][5].
[1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
[2] in https://phabricator.wikimedia.org/T324723
[3]
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Target_system
[4] https://phabricator.wikimedia.org/T328497
[5] https://phabricator.wikimedia.org/T328498
[6]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/885432/
default. Previously they would only load on the desktop site.
Hopefully this goes without disruption, but to be safe, if you maintain
code used in Wikimedia production, please:
1) check your experiences over the course of this week in mobile/desktop
site for JS errors/obvious UI errors (the former will be detected and
monitored via logstash)
2) check that your repository doesn't fail the core
testUnsatisfiableDependencies PHPUnit test. 3) Please check out the
following Phabricator tickets to see if you are impacted on the long term
[4][5].
# Background
Back in the early days of MobileFrontend, most of the JavaScript we had was
not mobile friendly. To avoid this we created an allow-list system, where
JavaScript was disabled by default and extensions/skins had to explicitly
enable it by adding a "targets" property to their ResourceLoaderModule
definition.
This was meant as a short term solution, but as with many things, attention
got pulled elsewhere, and almost ten years later it was still there.
There have been many complaints about this over those years. Mainly:
1) It means we have split the ResourceLoader cache further
2) It's not intuitive - new code was getting shipped to desktop only
experiences by default.
It also featured on the Developer Wishlist of 2017 at #34 [1].
3) Many older features don't work for community members for no credible
reason.
# Recent developments
As one of the few remaining people responsible for doing this in the first
time, I felt obliged to spend some time over December trying to pay off
this technical debt. I audited code that was being removed by the targets
system [2] and made the target explicit. Where modules were problematic on
mobile, we marked them in such a way that it was clear that they should
only run in a certain mode. This was only possible thanks to attention from
Amir, Santosh, Thiemo, Lucas W, Tpt, Sohom D, Bartosz - thank you all.
Today, Roan merged a change that makes ResourceLoader modules default to
the desktop AND mobile sites. This should be a harmless change, but may be
unintentionally triggering failures in testUnsatisfiableDependencies tests
as it seems some extension/skins are not included in the MediaWiki core
PHPUnit test run. If you encounter this issue, the fix is relatively simple
- you must define targets explicitly (see this example [6] and apologies in
advance for any annoyance this may cause)
# For action
Please take extra care with your code that you test on both mobile/desktop
sites and at mobile/desktop breakpoints. It's still possible to ship code
to mobile/desktop and see these guidelines [3] if you need to do that or
reply to this email with any questions you have.
# Next steps
This change will help with limiting the targets system to existing known
cases. This has been a long term request of the performance team. Please
see the follow up tickets to see if there is any action from you at your
leisure [4][5].
[1] https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
[2] in https://phabricator.wikimedia.org/T324723
[3]
https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Target_system
[4] https://phabricator.wikimedia.org/T328497
[5] https://phabricator.wikimedia.org/T328498
[6]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PropertySuggester/+/885432/