Change Details

**Background**: there are several mainly-JS libraries used by Wikibase and installed during Wikidata build step. These include: - serialization/javascript - data-values/javascript - data-values/value-view - wikibase/data-model-javascript - wikibase/javascript-api - wikibase/serialization-javascript All of these libraries contain some PHP code interacting with MedaWiki and are installed as PHP dependencies from Packagist using Composer. All of them are actually independent from MediaWiki. The only thing they do is registering their code as ResourceLoader modules, and currently also registering QUnit tests to be run using MW test loader. The latter is out of scope here as has been already tackled separately. **Problem**: as all these libraries are required by Wikibase/Wikidata, they must be also be deployed together. Unlike other library dependencies of Wikibase, these libraries could not be moved to mediawiki-vendor as they do have MW stuff in them (as said above). Also, ResourceLoader must be able to find files used by modules defined by these libraries. Below there is a list of options we've come up with so far. This ticket is a place to ask questions, discuss those options, suggest new ones, etc. 1. Move all those libraries to Wikibase git repository - pro: dependency problem goes away - con: code provided by those libs is no longer versioned as now - all only work with current Wikibase master - con: even more code in Wikibase.git - con: no way for those libs to by used by other users than Wikibase (but are there any?) 2. Turn those libs into npm packages and check in them into a particular place in Wikibase git repository to be picked up by RL - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - con: libs are maintained in two places - con: needs manual committing after each release of a lib (Composer no longer used) 3. Turn those libs into npm packages and add them as git submodules to Wikibase git repository - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - con: still requires manual action after new version of a lib is released (commiting the update submodule reference) - con: using git submodules might cause issues with CI and/or deploying the code? 4. Turn those libs into npm packages and have a script that pulls the required version of each lib (e.g. using Wikibase's package.json) into a known location next to other Wikibase code - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - how to ensure local changes are not made though? Just ignore this fact? - con: the "build" step is not entirely removed - could running this script be somehow synced/co-triggered with cutting the deployment branch of Wikibase, so that the process actually is automated? Any other options to be considered here? Bonus question: data-values/data-types contains both PHP and JS code ("real" PHP code, not just RL modules). How to deal with it? Split the JS part of out it and handle as other JS-only libs?

**Background**: there are several mainly-JS libraries used by Wikibase and installed during Wikidata build step. These include: - serialization/javascript - data-values/javascript - data-values/value-view - wikibase/data-model-javascript - wikibase/javascript-api - wikibase/serialization-javascript All of these libraries contain some PHP code interacting with MedaWiki and are installed as PHP dependencies from Packagist using Composer. All of them are actually independent from MediaWiki. The only thing they do is registering their code as ResourceLoader modules, and currently also registering QUnit tests to be run using MW test loader. The latter is out of scope here as has been already tackled separately. **Problem**: as all these libraries are required by Wikibase/Wikidata, they must be also be deployed together. Unlike other library dependencies of Wikibase, these libraries could not be moved to mediawiki-vendor as they do have MW stuff in them (as said above). Also, ResourceLoader must be able to find files used by modules defined by these libraries. Below there is a list of options we've come up with so far. This ticket is a place to ask questions, discuss those options, suggest new ones, etc. 1. Move all those libraries to Wikibase git repository - pro: dependency problem goes away - con: code provided by those libs is no longer versioned as now - all only work with current Wikibase master - con: even more code in Wikibase.git - con: no way for those libs to by used by other users than Wikibase (but are there any?) 2. Turn those libs into npm packages and check in them into a particular place in Wikibase git repository to be picked up by RL - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - con: libs are maintained in two places - con: needs manual committing after each release of a lib (Composer no longer used) 3. Turn those libs into npm packages and add them as git submodules to Wikibase git repository - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - con: still requires manual action after new version of a lib is released (commiting the update submodule reference) - con: using git submodules might cause issues with CI and/or deploying the code? 4. Turn those libs into npm packages and have a script that pulls the required version of each lib (e.g. using Wikibase's package.json) into a known location next to other Wikibase code - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - how to ensure local changes are not made though? Just ignore this fact? - con: the "build" step is not entirely removed - could running this script be somehow synced/co-triggered with cutting the deployment branch of Wikibase, so that the process actually is automated? Any other options to be considered here? Bonus question: data-values/data-types contains both PHP and JS code ("real" PHP code, not just RL modules). How to deal with it? Split the JS part of out it and handle as other JS-only libs? See also: {T107561}

**Background**: there are several mainly-JS libraries used by Wikibase and installed during Wikidata build step. These include: - serialization/javascript - data-values/javascript - data-values/value-view - wikibase/data-model-javascript - wikibase/javascript-api - wikibase/serialization-javascript All of these libraries contain some PHP code interacting with MedaWiki and are installed as PHP dependencies from Packagist using Composer. All of them are actually independent from MediaWiki. The only thing they do is registering their code as ResourceLoader modules, and currently also registering QUnit tests to be run using MW test loader. The latter is out of scope here as has been already tackled separately. **Problem**: as all these libraries are required by Wikibase/Wikidata, they must be also be deployed together. Unlike other library dependencies of Wikibase, these libraries could not be moved to mediawiki-vendor as they do have MW stuff in them (as said above). Also, ResourceLoader must be able to find files used by modules defined by these libraries. Below there is a list of options we've come up with so far. This ticket is a place to ask questions, discuss those options, suggest new ones, etc. 1. Move all those libraries to Wikibase git repository - pro: dependency problem goes away - con: code provided by those libs is no longer versioned as now - all only work with current Wikibase master - con: even more code in Wikibase.git - con: no way for those libs to by used by other users than Wikibase (but are there any?) 2. Turn those libs into npm packages and check in them into a particular place in Wikibase git repository to be picked up by RL - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - con: libs are maintained in two places - con: needs manual committing after each release of a lib (Composer no longer used) 3. Turn those libs into npm packages and add them as git submodules to Wikibase git repository - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - con: still requires manual action after new version of a lib is released (commiting the update submodule reference) - con: using git submodules might cause issues with CI and/or deploying the code? 4. Turn those libs into npm packages and have a script that pulls the required version of each lib (e.g. using Wikibase's package.json) into a known location next to other Wikibase code - pro: easy integration with RL (know where files are) - pro: libs can be still released and developed independently from Wikibase/MW - pro: libs only maintained in a single place - how to ensure local changes are not made though? Just ignore this fact? - con: the "build" step is not entirely removed - could running this script be somehow synced/co-triggered with cutting the deployment branch of Wikibase, so that the process actually is automated? Any other options to be considered here? Bonus question: data-values/data-types contains both PHP and JS code ("real" PHP code, not just RL modules). How to deal with it? Split the JS part of out it and handle as other JS-only libs? See also: {T107561}