WikibaseLexeme
MediaWiki WikibaseLexeme extension
|
The recommended way of setting up the development environment is with the use of the mwcli tool. To create a local MediaWiki development environment using this tool, see the docker development environment guide in the tool's documentation.
Note: All following command examples will be using the mwcli tool, but can also be run with docker or on bare metal according to preference.
The WikibaseLexeme extension also requires Wikibase to be set up and configured in your local MediaWiki instance. To get up and running with Wikibase, follow the installation instructions on MediaWiki.
Both Wikibase and WikibaseLexeme rely on the composer merge plugin for MediaWiki. To ensure the plugin is configured correctly, double check your composer.local.json
file in your local MediaWiki directory against the instructions on the MediaWiki website.
Clone this repository to the extensions/
directory in your local MediaWiki directory:
To initialize and update git submodules run:
Add the following line to LocalSettings.php
at the root of you MediaWiki directory, to enable the extension:
To ensure all composer dependencies are installed, run composer from the root of your MediaWiki instance:
Install all npm dependencies in order to use node development tools and scripts, using mwcli fresh:
The code for the Special:NewLexeme special page lives in a separate Git repository, included as a submodule under resources/special/new-lexeme/
. That directory is not directly used at runtime, but rather the build results from it are stored in this repository under resources/special/new-lexeme-dist/
. The following command updates the submodule to the latest main
branch and adds a new build to Git, ready to be committed here:
This command should be run from time to time (but not necessarily for every new commit in the submodule). Note: this command must be run outside a container.
If you try to update the submodule right after merging a commit on GitHub, you might see the following error message in CI:
In that case, just try again a bit later.
The background is, that due to operational reasons, CI will not pull the code from a GitHub remote. Therefore a mirror in Phabricator's Diffusion is used instead (see T301273). Its update frequency is dynamic and can be seen on its status page.
When you are working with the submodule, and want to see the current status of your work, you can use the following command to build and copy whatever is currently in the directory:
Then go to Special:NewLexeme on your wiki and see the result.
Historical note: during development, the current special page was called Special:NewLexemeAlpha, and Special:NewLexeme was a separate (older) implementation of similar functionality, which was eventually replaced with the new implementation. You might come across the NewLexemeAlpha name in git logs or similar.
PHP tests can be found in tests/phpunit directory.
You can run tests using composer as so:
More information about running PHP unit tests with mwcli can be found in the mwcli interaction instructions.
JavaScript tests are to be found in two directories:
tests/qunit
(tests depending on MediaWiki)tests/jasmine
(do not require MediaWiki)JavaScript tests are run using MediaWiki test runner, except for tests of several UI widgets which are independent from MediaWiki which can by run using nodejs.
MediaWiki runner could run JavaScript tests of the extension by either opening the Special:JavaScriptTest page in the browser, or by running the following in the main directory of the MediaWiki installation (this will run all QUnit tests of the MediaWiki installation):
Jasmine tests could be run from the WikibaseLexeme main directoday using:
For more information see the [Mediawiki manual for Javascript tests](https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing.
We use Cypress for browser testing. See the Cypress README for details.
To add a new language code for lexemes please refer to the detailed manual.
Configuration files for several linters etc are also provided. The easiest way to run these along with tests, is to either run mw dev mediawiki composer test
(for PHP code), or mw dev mediawiki fresh grunt test
(for JavaScript part).
As of November 2023, we have to update dependencies manually because LibraryUpgrader (LibUp) is broken: T345930
You can see which dependencies have new releases by first making sure your local dependencies are up-to-date by executing npm ci
and then running npm outdated
. The following dependencies are special cases that should potentially be ignored:
.eslintrc.json
) since version 25.0.0 because of changes since eslint 9 (see issue #176). See T364065 for progress with our eslint 9 migration.All other dependencies should generally be updated to the latest version. If you discover that a dependency should not be updated for some reason, please add it to the above list. If a dependency can only be updated with substantial manual work, you can create a new task for it and skip it in the context of the current chore.
The recommended way to update dependencies is to collect related dependency updates into grouped commits; this keeps the number of commits to review manageable (compared to having one commit for every update), while keeping the scope of each commit limited and increasing reviewability and debuggability (compared to combining all updates in a single commit). For example, this can be one commit for each of:
npm update
for all other dependency updatesMake sure that all checks still pass for every commit.
Make sure your local dependencies are up-to-date by running composer update
, then run composer outdated --direct
to check that direct dependencies are up to date. There are no special cases to take into account here, and most of the time, there are few enough libraries to upgrade that no grouping is necessary.