Yesterday I released a new feature in the Maps extension that uses the
mediawiki.api.edit resource loader module.
I developed this against MediaWiki 1.31 (the latest LTS and minimum version
of MediaWiki required by Maps). Today I found out that things are broken on
MediaWiki 1.33.0. Apparently the mediawiki.api.edit resource loader module
What is the deprecation policy for such modules? I was rather surprised
that a module with no sign of deprecation is gone 2 releases later, without
any form of fallback.
And more importantly, how can I now make my code work with both MW 1.31 and
1.33? I see that on MW master, the relevant JS file is now part of the
mediawiki.api module. I could include both modules, which would work fine
on MW 1.31, though on 1.33 I'd still have a reference to a module that does
not exist. And since my own module definition is in JSON (extension.json),
I can't even check which MW version I'm dealing with (unless there is some
special syntax for this). I'm not seeing a sane solution that I can use
here, so help is much appreciated.
On Wed, 2019-09-25 at 05:44 +0200, Jeroen De Dauw wrote:
> Yesterday I released a new feature in the Maps extension that uses the
> mediawiki.api.edit resource loader module.
> I developed this against MediaWiki 1.31 (the latest LTS and minimum version
> of MediaWiki required by Maps). Today I found out that things are broken on
> MediaWiki 1.33.0. Apparently the mediawiki.api.edit resource loader module
> got removed.
Formally, this policy only applies to PHP code. The Scope section says:
"This proposed policy applies to the PHP API of the MediaWiki core
(mediawiki/core.git) codebase. It explicitly does not apply to the api.php API,
I don't know if we even have a policy for the removal of JS modules. It would
certainly be a good idea to have one, so we don't randomly break custom JS code...
Principal Software Engineer, Core Platform
I think the least inconvenient solution would be to leave your
dependency on 'mediawiki.api.edit' in extension.json unchanged, and
conditionally register that module as an "alias" for mediawiki.api if it
doesn't exist, using the ResourceLoaderRegisterModules hook.
You could even be super lazy and register it unconditionally in
extension.json, it seems that the module from core will take precedence
if it exists, but ResourceLoader will apparently log a warning for this.