Page MenuHomePhabricator

Copy dependencies of "jquery.wikibase.linkitem" Resource Loader module to Wikibase client JS code
Closed, ResolvedPublic

Description

As a Wikibase Client JS developer I want quickly make jquery.wikibase.linkitem independent from modules outside of Wikibase client, in order to be able to change it freely without loading non-client modules.

Following on the finding of T255115, as an intermediate step "jquery.wikibase.linkitem" is to be made independent from Resource Loader modules defined outside of Wikibase client by copying over its dependencies to client directory, and making the said modules depend on those copies.

Dependencies:

Direct ResourceLoader Modules

//...

'dependencies' => [
    'jquery.spinner', // Not in Wikibase
    'jquery.ui', // Not in wikibase
    'jquery.ui.suggester', // WikibaseLib
    'jquery.wikibase.siteselector', // WikibaseLib
    'jquery.wikibase.wbtooltip', // WikibaseLib
    'mediawiki.api', // Not in wikibase
    'mediawiki.util', // Not in wikibase
    'mediawiki.jqueryMsg', // Not in wikibase
    'jquery.event.special.eachchange', // WikibaseLib
    'wikibase.sites', // WikibaseLib
    'wikibase.api.RepoApi', // WikibaseLib
]

//...

jQuery Widgets

Direct usage:

  • wikibase.siteselector
  • wikibase.wbtooltip
  • ui.suggester

Transitive Usage:

  • ui.ooMenu

Global Variables

  • wikibase.sites <-- Defined in WikibaseLib
  • wikibase.api <-- Defined in WikibaseLib

Copies are to not be prevented from possibly diverging from their source files.

Acceptance criteria:

  • jquery.wikibase.linkitem only depends on modules defined and containing files from the wikbase client part

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 609275 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Make linkitem module use packageFiles instead of scripts

https://gerrit.wikimedia.org/r/609275

Change 609416 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Decouple wikibase.sites RL modules between repo and client

https://gerrit.wikimedia.org/r/609416

I give up on this for now, everything is entangled :((

Cleaning up the code a bit before moving them around.

Change 609793 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Bump wikibase-api and wikibase-data-model

https://gerrit.wikimedia.org/r/609793

Change 609807 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] [WIP] Decouple eachchange.js

https://gerrit.wikimedia.org/r/609807

Change 609793 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Bump wikibase-api and wikibase-data-model

https://gerrit.wikimedia.org/r/609793

Change 609836 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[data-values/value-view@master] Remove unused code

https://gerrit.wikimedia.org/r/609836

Change 609836 merged by jenkins-bot:
[data-values/value-view@master] Remove unused code

https://gerrit.wikimedia.org/r/609836

Change 610110 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Bump wikibase-data-values-value-view to HEAD

https://gerrit.wikimedia.org/r/610110

Change 609275 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Make linkitem module use packageFiles instead of scripts

https://gerrit.wikimedia.org/r/609275

Change 610110 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Bump value view and data values libs to HEAD

https://gerrit.wikimedia.org/r/610110

Change 609416 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Decouple wikibase.sites RL modules between repo and client

https://gerrit.wikimedia.org/r/609416

Change 610898 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Decouple jquery.event.special.eachchange and util.inherit

https://gerrit.wikimedia.org/r/610898

Change 609807 abandoned by Ladsgroup:
[mediawiki/extensions/Wikibase@master] Decouple eachchange.js

Reason:
Done in Icad3c338cf

https://gerrit.wikimedia.org/r/609807

Change 610903 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Clean up qunit tests in lib

https://gerrit.wikimedia.org/r/610903

Change 610903 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Clean up qunit tests in lib

https://gerrit.wikimedia.org/r/610903

Change 611415 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Fix use of wb.sites in PageConnector

https://gerrit.wikimedia.org/r/611415

Change 611415 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Fix use of wb.sites in PageConnector

https://gerrit.wikimedia.org/r/611415

Change 610898 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Decouple jquery.event.special.eachchange and util.inherit

https://gerrit.wikimedia.org/r/610898

Change 612401 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Move wikibase.api.ValueCaller RL module from lib to view

https://gerrit.wikimedia.org/r/612401

The above patch is the last thing I can do to make it decoupled without weird gymnastics, there are five more that I don't know if there's a way to decouple them properly:

  • mw.config.values.wbSiteDetails: Build using php code living in lib, heavily used in both client and repo: https://codesearch.wmflabs.org/search/?q=wbSiteDetails&i=nope&files=&repos=
    • We might split the php file into two and copy them?
  • mw.config.values.wbRepo: Same, heavily used everywhere.
  • wikibase basic nonsense code that defines wikibase global object which is used everywhere.
  • wikibase.api.RepoApi: both client and repo depend on it and the obvious solution is to copy-paste it in both places but all of the code lives in a git submodule.
    • Have two identical submodule?
    • Don't give a damn and define it twice while both pointing to the same file, how is it different from status quo?
  • wikibase.Site defined dynamically through a hook in lib. Fun.
    • Copy the hook handler and the code?

It seems like for the wikibase api stuff we should probably take advantage of the fact it is a pseudo-npm module. I'm trying to think how

Change 612401 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Move wikibase.api.ValueCaller RL module from lib to view

https://gerrit.wikimedia.org/r/612401

The above patch is the last thing I can do to make it decoupled without weird gymnastics, there are five more that I don't know if there's a way to decouple them properly:

As they both rely on php code, it seems like the easier option, but there's probably more digging around to do here.

  • wikibase basic nonsense code that defines wikibase global object which is used everywhere.

The fact that it's nonsensical global var bootstrapping means we can probably safely duplicate this file to client. as long as the sub-namespaces are available:

wikibase.sites <-- Defined in WikibaseLib
wikibase.api <-- Defined in WikibaseLib

  • wikibase.api.RepoApi: both client and repo depend on it and the obvious solution is to copy-paste it in both places but all of the code lives in a git submodule.
    • Have two identical submodule?
    • Don't give a damn and define it twice while both pointing to the same file, how is it different from status quo?

IMHO this is a perfect candidate for a JS module to test the monorepo approach with.

  • wikibase.Site defined dynamically through a hook in lib. Fun.
    • Copy the hook handler and the code?

I don't think it is necessary to copy the code, shouldn't we follow ADR 13 in this case and just define the hook both in extension-repo.json and extension-client.json?

The above patch is the last thing I can do to make it decoupled without weird gymnastics, there are five more that I don't know if there's a way to decouple them properly:

As they both rely on php code, it seems like the easier option, but there's probably more digging around to do here.

I'm not sure it'll be possible for the second one.

  • wikibase basic nonsense code that defines wikibase global object which is used everywhere.

The fact that it's nonsensical global var bootstrapping means we can probably safely duplicate this file to client. as long as the sub-namespaces are available:

wikibase.sites <-- Defined in WikibaseLib
wikibase.api <-- Defined in WikibaseLib

Yeah, let's do that. I make a patch for this one.

  • wikibase.api.RepoApi: both client and repo depend on it and the obvious solution is to copy-paste it in both places but all of the code lives in a git submodule.
    • Have two identical submodule?
    • Don't give a damn and define it twice while both pointing to the same file, how is it different from status quo?

IMHO this is a perfect candidate for a JS module to test the monorepo approach with.

  • wikibase.Site defined dynamically through a hook in lib. Fun.
    • Copy the hook handler and the code?

I don't think it is necessary to copy the code, shouldn't we follow ADR 13 in this case and just define the hook both in extension-repo.json and extension-client.json?

That's the status quo but the code sits in one place for both classes, meaning they are shared and coupled.

Change 612597 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Migrate wikibase.api module to repo and use it directly in client

https://gerrit.wikimedia.org/r/612597

Change 612615 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Migrate 'wikibase' RL module to view

https://gerrit.wikimedia.org/r/612615

Change 612597 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Migrate wikibase.api module to repo and use it directly in client

https://gerrit.wikimedia.org/r/612597

Change 612615 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Migrate 'wikibase' RL module to view

https://gerrit.wikimedia.org/r/612615

I have some long-term ideas on how to proceed for mw.config.values.wbSiteDetails and mw.config.values.wbRepo. The problem with these modules is that they are polymorphic (the same config behaves differently in a repo and client, they are pretending to be the same thing but they are not) and they even too outdated to be useful (which repo? commons or wikidata?). I think they need to be deprecated and broken apart. It's way out of scope of this hike and not a small size of work either. We can outline this and leave it for future devs to pick it up.

Also I found some more dead code (by removing dead code, you uncover more). Deleting them is not easy for a stupid reason: Their tests are convoluted so for example I can't drop getDataValues because the test for hasDataValues uses it...

amsa@amsa-Latitude-7480:~/workspace$ python unused_js_functions.py ~/Wikibase
/home/amsa/Wikibase/view/lib/wikibase-data-values/src/dataValues.js getDataValues
/home/amsa/Wikibase/view/lib/wikibase-data-values/src/dataValues.js hasDataValue
/home/amsa/Wikibase/view/lib/wikibase-data-model/src/Fingerprint.js hasLabel
/home/amsa/Wikibase/view/lib/wikibase-data-model/src/Fingerprint.js hasDescription
/home/amsa/Wikibase/view/lib/wikibase-data-model/src/Fingerprint.js hasAliases

Change 612671 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/extensions/Wikibase@master] Removing dead code in client javascript

https://gerrit.wikimedia.org/r/612671

Change 612671 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Removing dead code in client javascript

https://gerrit.wikimedia.org/r/612671

Okay, I don't think we can do much more than this. Three RL modules left out of ~15 and I think we can outline a long-term plan to fix it but not doable in this hike.

Suggestion: Create tickets for deprecating the configs and call this task done. What do you think @Lucas_Werkmeister_WMDE @Tarrow

Suggestion: Create tickets for deprecating the configs and call this task done. What do you think @Lucas_Werkmeister_WMDE @Tarrow

Sounds good to me.