Thijs/wiki.techinc.nl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki.techinc.nl/composer.json

219 lines
8.2 KiB
JSON
Raw Normal View History

Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
{
"name": "mediawiki/core",
"description": "Free software wiki application developed by the Wikimedia Foundation and others",
Set the package type to 'mediawiki-core' Since mediawiki is not a library, the package type should be custom. Bug: T190386 Change-Id: Ic31083427af7f70874ccd8acf34336b0e9a562d4
2018-03-22 05:16:59 +00:00
"type": "mediawiki-core",
build: Updating npm dependencies * ini: 1.3.5 → 1.3.8 * https://npmjs.com/advisories/1589 Additional changes: * Removed useless -p option to phpcbf in "composer fix" command. * Set `root: true` in .eslintrc.json (T206485). Change-Id: I0116578751fd73e43b07c2830adc629f4b85c784
2021-01-03 22:29:28 +00:00
"keywords": [
"mediawiki",
"wiki"
],
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"homepage": "https://www.mediawiki.org/",
"authors": [
{
"name": "MediaWiki Community",
"homepage": "https://www.mediawiki.org/wiki/Special:Version/Credits"
}
],
Use SPDX 3.0 license identifier SPDX released version 3 of their license list (<https://spdx.org/licenses/>), which changed the FSF licenses to explicitly end in -only or -or-later instead of relying on an easy to miss + symbol. Bug: T183858 Change-Id: I4cbb98ea2bbacf46a57401dbba2bdb076fca1d3a
2018-03-06 01:14:07 +00:00
"license": "GPL-2.0-or-later",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"support": {
composer.json: Link directly to https://phabricator.wikimedia.org Although https://bugs.mediawiki.org will redirect to our Phabricator domain, let's just update this to reflect reality. But if there is a specific reason to point users to the old domain and allow it to redirect, please let me know. Change-Id: Ib91de8f949eb1c1d718e0e460b1a317983df4ad9
2023-06-03 08:12:11 +00:00
"issues": "https://phabricator.wikimedia.org/",
Freenode -> Libera per wikimedia moving from freenode to libera Bug: T283247 Change-Id: Iebbb13ac53830a8d77b42bf2954cf80d76d78467
2021-05-20 20:57:48 +00:00
"irc": "irc://irc.libera.chat/mediawiki",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"wiki": "https://www.mediawiki.org/"
},
Add Parsoid as a library dependency As Parsoid (including its integration with core) is still in active development, we are using a '^0.12.0' version constraint for now. This allows us to update Parsoid on both the production cluster and the Parsoid cluster by updating the mediawiki-vendor repository (composer.json/composer.lock/etc) without requiring further weekly changes to core's `composer.json`. We will convert this loose constraint to a standard precise constraint when we branch core for release. This commit just adds parsoid as a library. A follow-on commit (Ie336f69692317d7a714809b42e035fb188e66fc0) then removes the auto- loading of Parsoid from the Parsoid extension. This patch doesn't (yet) create any specific uses of Parsoid from the core codebase, but that is expected to follow rapidly once we work through this initial deploy/release process hurdle. Bug: T213494 Bug: T239660 Bug: T240055 Depends-On: I4c0367d6424513767751a2fc1dbe882250bef242 Change-Id: I8b3d3591b9a4f2a48ac83e1d242755c43b223aba
2020-02-13 17:03:07 +00:00
"prefer-stable": true,
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"require": {
Upgrade mediawiki/mediawiki-codesniffer from 44.0.0 to 45.0.0 and composer/semver from v3.4.2 to v3.4.3 Bug: T375310 Depends-On: I7245d5d0dd5ccdfc483c5dc95690b8971a8f0bac Change-Id: I4c0e4eac206035dfbd9d7268fbd895c16957d4da (cherry picked from commit 2869a7e77cea2f4a4f5b712b758a31f40c961924)
2024-10-07 13:26:22 +00:00
"composer/semver": "3.4.3",
Update cssjanus/cssjanus to 2.3.0 Bug: T371466 Depends-On: I16df3d0e271f38e611dddd3632544d102c9c1613 Change-Id: I8b459bfd2967a76aa1eb460ab474919ba9662083
2024-08-06 20:52:11 +00:00
"cssjanus/cssjanus": "2.3.0",
composer.json: Add ext-calendar to require Used by HistoryAction Bug: T302540 Change-Id: I8e77efa1192a3c5b61c36a674d991389e6aba8cb
2022-02-25 12:41:42 +00:00
"ext-calendar": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-ctype": "*",
Add ext-dom to composer.json In most cases it's packaged as part of the php xml extension but there's likely some OS that maybe package it separately.... Shouldn't cause any harm being here Change-Id: I6c8a40a06314e7e4eb3fe83448a2a071e8203554
2019-07-30 20:17:16 +00:00
"ext-dom": "*",
composer.json, require ext-fileinfo PHPVersionCheck requires fileinfo be installed for mime_content_type Change-Id: Iea7d2c7842c770e77c05265d4f4b08b17f9ab71f
2018-09-24 08:25:53 +00:00
"ext-fileinfo": "*",
Require ext-iconv and suggest ext-intl in composer.json Since iconv is required, per running install.php, and intl is recommended. Bug: T90439 Change-Id: I70f6ce9d8d71f8abd3800bbe00aa0f754ce297a2
2015-02-23 15:03:24 +00:00
"ext-iconv": "*",
Mention new required php extension intl This requirement was introduced in: Ic721b9a91e78e4ef07040339d1006b7a90a910c0 Bug: T267669 Change-Id: Iacadf9d4afdaa58e2c03fa50b04aa40a7d668dd8
2020-11-10 17:53:48 +00:00
"ext-intl": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-json": "*",
composer.json: Add ext-libxml and ext-xmlreader to requires Change-Id: I1c82ec4f2b521ff9dc2d4604cf1007847f32f7de
2020-12-27 16:04:42 +00:00
"ext-libxml": "*",
Kill mbstring fallbacks In the age when we require PHP 5.5, pretending that mbstring emulation is not slow and silly is silly. Bug: T129435 Change-Id: Ic8235c9da9a926df63ec7388900c44eab454eebe
2016-01-29 19:42:44 +00:00
"ext-mbstring": "*",
Move ext-openssl from suggest to require openssl provides the proper password hashing algorithm, so it is needed in order to have safe and efficent password hashing. Change-Id: I61498275c7f7cf19787f0aee50dc4884c57b82b2
2024-05-05 08:56:08 +00:00
"ext-openssl": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-xml": "*",
composer.json: Add ext-libxml and ext-xmlreader to requires Change-Id: I1c82ec4f2b521ff9dc2d4604cf1007847f32f7de
2020-12-27 16:04:42 +00:00
"ext-xmlreader": "*",
Updated guzzlehttp/guzzle from 7.8.1 to 7.9.2 Bug: T378306 Change-Id: Ic29aa0674904f7a89b58600caa448370cdb4e72a Depends-On: I8fde4133d0485dd42e332ac7123046aa7b691205 (cherry picked from commit 0f3c06900813aab90673c1c38d41843f82020ae8)
2024-10-27 22:36:18 +00:00
"guzzlehttp/guzzle": "7.9.2",
Updated justinrainbow/json-schema from 5.2.13 to 5.3.0 Bug: T379377 Change-Id: I7a044533ebfe8a726bf2c94521c79856c3bbcd63 Depends-On: I153db8f19aa2ac06f0ad3ad9691a84bd7bfaddf0 (cherry picked from commit 442b4a7a57894c255f4cf8076d8d204cdae7dc2c)
2024-11-09 20:38:47 +00:00
"justinrainbow/json-schema": "5.3.0",
Update liuggio/statsd-php-client to 1.0.18 Depends-On: I81a7d7da30374072c78c51d1a7fe8229cd70d42c Change-Id: Ibf06b3b97eb6002c1ad2666f38764b44fc716ef3
2015-11-23 00:37:33 +00:00
"liuggio/statsd-php-client": "1.0.18",
composer.json: Update mck89/peast from 1.16.2 to 1.16.3 Bug: T376276 Change-Id: I8e6affc244ba155ebe5ff0f38817a21506260c18 Depends-On: I7c90510115eb1d9da3e86f81b557af8c1c013e83 (cherry picked from commit 26356e9b39d024459b3ea75254d3e87263fd94d9)
2024-11-11 02:11:40 +00:00
"mck89/peast": "1.16.3",
Update monolog/monolog to 2.9.3 Depends-On: Ic19219cd84b96a006cf0620d56f33a951e060eb9 Change-Id: Iabfc3d4ad49125214203549032cbe8f291ffa087
2024-05-03 19:55:00 +00:00
"monolog/monolog": "2.9.3",
Update OOUI to v0.51.2 Release notes:https://gerrit.wikimedia.org/g/oojs/ui/+/v0.51.2/History.md Bug: T210534 Bug: T324382 Bug: T376276 Depends-On: I50ec27302347203170cb14c7228b6c3d3264b24c Change-Id: Iea7cbc00d988504660754e8728707d0021ae37d7 (cherry picked from commit eb6a4ea1ae271668a0ef78e86ccc180d84614e68)
2024-11-13 16:44:23 +00:00
"oojs/oojs-ui": "0.51.2",
Updated pear/mail from 1.6.0 to 2.0.0 Change-Id: Ice89888216220612bae0f5597e2bbde9b9bd3bf1 Depends-On: I19d29ef502f4647da6a2249180bdc9f612335085 (cherry picked from commit 80f352656364e5ec769fb8e1868499980e15b2ff)
2024-11-09 22:55:30 +00:00
"pear/mail": "2.0.0",
Update pear/mail_mime (1.10.11 => 1.10.12) Depends-On: Iaec742e75809b43d0405d591e1afdcc9e550f491 Change-Id: I6b509264e8f43dac34c624815d994597b9fc60f9
2024-04-05 20:23:35 +00:00
"pear/mail_mime": "1.10.12",
Updated pear/net_smtp from 1.11.1 to 1.12.1 Depends-On: I5a62ce8f667de2491060e0f5a1ee7bea58cf0f3f Change-Id: Ib8bec48952acff9fbb0d76853036ee19ac8bd849
2024-05-03 13:51:19 +00:00
"pear/net_smtp": "1.12.1",
Bump PHPVersionCheck & composer expected PHP versions to 8.1.0 As in T328921#9620620 and Ifa46fb69792943a17ae9f0b991abede67809cd45 Change-Id: I30440d97f4f7bd5fa9a38240663a572dea0eb926
2024-10-25 23:56:22 +00:00
"php": ">=8.1.0",
Upgrading psr/container (1.1.1 => 1.1.2) Depends-On: I6f1fa59ee47890ca0f4325d91b37ccc38e9dacd8 Change-Id: Ifd07f36903df87f171d220d6c9180196d9dc2e83
2023-01-15 15:52:53 +00:00
"psr/container": "1.1.2",
Upgrading psr/http-message (1.0.1 => 1.1) Depends-On: I313604124b149d6229643192c5e98a4025f18171 Change-Id: I30cb9f73692a40988452b5ea21b7a6d7847537b7
2023-12-21 22:04:52 +00:00
"psr/http-message": "1.1",
Upgrading psr/log (1.1.3 => 1.1.4) Change-Id: If11d0081355eb9caa157fb92389d92ac65b27d4e Depends-On: I5c4006f5747075a92a78900606e196d33c6d9a8f
2021-10-08 19:36:55 +00:00
"psr/log": "1.1.4",
WebRequest & RequestFromGlobals: get HTTP headers in one way apache_request_headers() is a vendor-specific function - it got used when present and alternative code paths were exercised otherwise. These preserved certain "special" headers, e.g. Content-Type, only inconsistently. The function getallheaders() is an alias[1] for apache_request_headers() on systems where the latter is present. Alternatively, there is a polyfill (ralouphie/getallheaders) which is already installed in mediawiki-vendor[2] (by virtue of guzzle). Using getallheaders() exclusively, will make sure these "special" headers are consistently available alongside their "regular"[3] peers and helps MediaWiki code focus on its domain. The dependency to ralouphie/getallheaders is made explicit in the same version in which it is currently locked in mediawiki-vendor[4]. This surfaced because the deprecation warning for API POST requests without a Content-Type header, introduced in bba1a0f, appeared in my development system (somewhat dated addshore/mediawiki-docker-dev/) even though the client did a fine job. Interesting implementation detail: While WebRequest keeps track of headers using keys in all upper case, REST RequestFromGlobals does so in all lower case - but both use retrieval logic complementary to their respective approach however. In case of REST RequestFromGlobals this is encapsulated inside of HeaderContainer (setting and retrieving), while WebRequest does all of this by itself. Cf. [5] and [6] [1]: https://www.php.net/manual/en/function.getallheaders.php [2]: https://github.com/wikimedia/mediawiki-vendor/tree/8f2967d/ralouphie/getallheaders [3]: https://www.php.net/manual/en/reserved.variables.server.php#110763 [4]: https://github.com/wikimedia/mediawiki-vendor/blob/8f2967d/composer.lock#L3250 [5]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 [6]: https://www.php.net/manual/en/function.apache-request-headers.php#124236 Bug: T245535 Change-Id: Iba52f152e15928473b729a2588c2462e76e85634
2020-03-18 08:49:15 +00:00
"ralouphie/getallheaders": "3.0.3",
Update symfony/* Depends-On: I8128035597dba96c269ae35c0439032821f63232 Change-Id: I200775b8b55679df154db00832405f17a8064890 (cherry picked from commit ac5143c64d73ff29bc9e3d49d3bfc7d76f7846b3)
2024-11-09 22:30:39 +00:00
"symfony/polyfill-php82": "1.31.0",
"symfony/polyfill-php83": "1.31.0",
"symfony/yaml": "5.4.45",
Update wikimedia/assert from 0.5.0 to 0.5.1 All libraries and extensions require ^0.5.0 so this should Just Work™. Bug: T287972 Depends-On: I38ff3873df866cd896c9028dc6277ac7aac8a932 Change-Id: I0689e447d7b603a347869aa442a58602f45b2647
2021-12-21 12:11:36 +00:00
"wikimedia/assert": "0.5.1",
Upgrade AtEase from 2.1.0 to 3.0.0 Bug: T376911 Depends-On: I39879b6a9aaef80f6a76bd09b72a97aa48fb8421 Depends-On: Ic3e749daf98742fe390420b7edcad95bde5ab79c Change-Id: I46edad548e0e2390cf79eec9c68c7cc4c3bf68f1
2024-10-15 14:02:56 +00:00
"wikimedia/at-ease": "3.0.0",
Upgrading wikimedia/base-convert (v2.0.1 => v2.0.2) Bug: T287972 Change-Id: I8458f98ec4b47369d53e8d2a42fb0cd24461b24c Depends-On: Ib90bff33eaa15714bcc6659456ab0c24cf13e71d
2022-07-08 22:31:49 +00:00
"wikimedia/base-convert": "2.0.2",
Bump wikimedia/bcp-47-code to 2.0.0 This adds Bcp47Code::isSameCodeAs() to the interface, which is implemented for the Language class in If3abc8a55eda8879ca904b25e9e3e5d40c1b0bab. Depends-On: I323ebdf3bfa9f8fae2fb6991880cceae250dcf20 Change-Id: I34edabc5a3b6dc82810e8d96c7ce0513d6f18428
2023-10-03 15:48:52 +00:00
"wikimedia/bcp-47-code": "2.0.0",
Update wikimedia/cdb from v2.0.0 to v3.0.0 https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/940957 Bug: T327992 Depends-On: I326f2929989eaf25b555d063acb821ad4d2cb2ac Change-Id: Ibecc4796dc9e898f07f9130fb6748e938d57b5ee
2023-07-24 14:58:57 +00:00
"wikimedia/cdb": "3.0.0",
Updating wikimedia/cldr-plural-rule-parser (v1.0.0 => v2.0.0) Bug: T263341 Change-Id: I27405756c5b6733c05ec0edd7cbc8239de20f05c Depends-On: Ic39d29d0579404fd9e4bedf2e2142c8ebe4a3902
2021-02-12 01:01:34 +00:00
"wikimedia/cldr-plural-rule-parser": "2.0.0",
Upgrade wikimedia/common-passwords to 0.5.0 Depends-On: I2cd9b5d1850b5c8013a199f5f23db5e34406352f Change-Id: Iff0d05731ea976fa06bc17717f52cf5a325520ed
2023-06-06 12:44:40 +00:00
"wikimedia/common-passwords": "0.5.0",
Upgrading wikimedia/composer-merge-plugin (v2.0.1 => v2.1.0) Change-Id: Ic081cf01b5c41d508652dd34af33085df21116d1 Depends-On: Ic3521d3b9c26fef9784459a46f8265eeedbd3ce4
2023-04-24 13:37:55 +00:00
"wikimedia/composer-merge-plugin": "2.1.0",
Bump wikimedia/html-formatter to 4.1.0 Bug: T345319 Bug: T348402 Depends-On: I769365369d4efbe6c8725dba18bc28d114cb6e03 Change-Id: I89e189f323d7372d94a30a7c04d606342ab6ae63
2024-03-13 18:00:36 +00:00
"wikimedia/html-formatter": "4.1.0",
build: Update wikimedia/ip-utils from 4.0.1 to 5.0.0 Depends-On: I01db4fe5735d5895f528620222d89b45e177685c Change-Id: I2415462044c6bc320c636b90be644546bebac8d9
2023-10-02 23:12:04 +00:00
"wikimedia/ip-utils": "5.0.0",
Upgrade wikimedia/json-codec from 3.0.2 to 3.0.3 Depends-On: I2a7da46c89694803060b9c450da06b14a5bd44ad Change-Id: I16e5d3bfa2067e7108fadabb04692955aa9c3bda (cherry picked from commit eda3b425939ce85352982d24394865b9327d0c95)
2024-11-09 05:52:49 +00:00
"wikimedia/json-codec": "3.0.3",
ResourceLoader: Update wikimedia/less.php from 5.1.1 to 5.1.2 Bug: T379438 Depends-On: I5fdc63ac02fb6bf979c723b0c2a8058f6674b2b7 Change-Id: Id91aa083651f9eaebf84593f65790854268f5f8d (cherry picked from commit 78e238c54f4df034964d8228f6f5566937cb598e)
2024-11-14 12:37:05 +00:00
"wikimedia/less.php": "5.1.2",
ResourceLoader: update wikimedia/minify to 2.9.0 Bug: T390063 Bug: T277675 Depends-On: I649b08e9b09e12a949f9cb92de501c0db9dd5c94 Change-Id: If12936df3910fe94c254d9caf6a3c7be65dcc15f (cherry picked from commit c324214f5242bbb05c2ebfb98da56d949ed67263)
2025-03-26 18:36:41 +00:00
"wikimedia/minify": "2.9.0",
Updated wikimedia/normalized-exception from 1.0.1 to 2.0.0 Bug: T379477 Change-Id: I2e81a65363681a63b02bc1fa9fa91ed3e2109acb Depends-On: I7effe25136e921224bd1565e00b55567e4a0f5a6 (cherry picked from commit 42c61fde49202429462518b492e830de9be275f4)
2024-11-12 20:04:46 +00:00
"wikimedia/normalized-exception": "2.0.0",
Upgrading wikimedia/object-factory (v4.0.0 => v5.0.1) Change-Id: Ie5d59d6582e9b28e65fa516ceb9f656a9aea0311 Depends-On: I8266aa783b063b394e50a9090c0a33a7d23ec3e9
2023-01-09 22:16:46 +00:00
"wikimedia/object-factory": "5.0.1",
Update wikimedia/parsoid to 0.20.3 Bug: T382963 Depends-On: I1ec004b6914173c14f66ac0300192035122f6ae0 Change-Id: I968df278a3aefec02e1b53aff484419311e5df34
2025-06-04 00:40:11 +00:00
"wikimedia/parsoid": "0.20.3",
Upgrade php-session-serializer from 2.0.1 to 3.0.0 The breaking change is dropped PHP 7.4 support. Depends-On: Ice6ed4d3fa376a37faae75d11cb81c9221f7f29f Change-Id: Ib74d84f753bf5230a0e1ab8c7f7f0c664f6ba4ce
2024-10-15 14:00:36 +00:00
"wikimedia/php-session-serializer": "3.0.0",
composer.json: Upgrade wikimedia/purtle to 2.0.0 Bug: T379479 Change-Id: I4a14f878b300261ed082bed90874f05257cceeeb Depends-On: I93d4c36a153a424eee220bb6d5f6ecf76d7fb6cf (cherry picked from commit b7534500dbb4e843134013a6e06a5122f38006b5)
2024-11-11 02:04:01 +00:00
"wikimedia/purtle": "2.0.0",
Upgrade wikimedia/relpath from 4.0.0 to 4.0.1 For back-porting immediately to REL1_43. Bug: T379480 Depends-On: I512e8102fbb9f82e444d5e0c097f0139a50c2013 Change-Id: Id57f41ed211f2d22395a2cd27af15d3c46b8cc22 (cherry picked from commit 4a33cbd228f738fefb09e476a3f2d9be6833e4ac)
2024-11-12 00:49:33 +00:00
"wikimedia/relpath": "4.0.1",
Updated wikimedia/remex-html from 4.1.0 to 4.1.1 Bug: T379082 Change-Id: I0737aee4b16c5d657670b9ff9e9f23610fd89c78 (cherry picked from commit 656b409efff29b144a6d7a5e82979ebe4cfb5dc5)
2024-11-05 21:10:48 +00:00
"wikimedia/remex-html": "4.1.1",
Updated wikimedia/request-timeout from 1.2.0 to 2.0.0 Change-Id: I9bf8eb7265848b52bfa2ca9cdf470d89b0ac12f2 Depends-On: I221aad58f2177031448966da61a8afd29f7f99ba (cherry picked from commit abd208e21815711226c6458557c2b87b91a35b7f)
2024-11-12 20:03:25 +00:00
"wikimedia/request-timeout": "2.0.0",
build: Update wikimedia/running-stat to 2.1.0 To be used in Scribunto, ref T313341. Bug: T313341 Depends-On: I6c5ab99fde1eeb2fb48f4d42c3e886484675aa86 Change-Id: Ica3f0c81305eec7d800c794030d8346a85ea84ac
2022-07-29 04:51:26 +00:00
"wikimedia/running-stat": "2.1.0",
Updated wikimedia/scoped-callback from 4.0.0 to 5.0.0 Bug: T378300 Change-Id: I9c4306842ae6a21000f14e2ac36052560f5423cb Depends-On: Ic224f2c33d76b1430c5faef6af341b256c3f4855 (cherry picked from commit 2b853b863b875678ca538a176c5f0bef794887ac)
2024-11-09 20:56:41 +00:00
"wikimedia/scoped-callback": "5.0.0",
Updated wikimedia/services from 3.0.0 to 4.0.0 Bug: T379384 Change-Id: Ia84fe750996a15370cf41a0a15bc77919dbc5abf Depends-On: I78e985d273146b71302f430201c1331bbecf1d8a (cherry picked from commit 81ae1abd7382fb5772191e350c596857f9d238ba)
2024-11-09 14:27:39 +00:00
"wikimedia/services": "4.0.0",
Update wikimedia/shellbox to 4.1.1 Bug: T378422 Change-Id: I715ab5d453a1001f2069cbcf7d74f88d01f743fd Depends-On: I211fc38b4b4c898b7e8428a22ed901a4114bf52b
2024-10-29 21:16:51 +00:00
"wikimedia/shellbox": "4.1.1",
Update wikimedia/utfnormal to latest 4.0.0 Depends-On: I8812c644b78527f2f165829ff372aeafb34ec81b Change-Id: I6e7dbaab8226af038d20a511a2d07eb59e5735f6
2023-08-29 16:02:36 +00:00
"wikimedia/utfnormal": "4.0.0",
Update Timestamp to v4.1.1 Bug: T347759 Depends-On: I5b738878223ed979eebbdef209984de74ff2fc9d Change-Id: I08a285ef4362f47a76e56db1aa493d14e10ed6a2
2023-09-29 19:05:16 +00:00
"wikimedia/timestamp": "4.1.1",
Update wikimedia/wait-condition-loop from 2.0.1 to 2.0.2 Bug: T289176 Bug: T287972 Depends-On: I009fde18d039ede388a758021651961f0c0f13b0 Change-Id: I9bf513183672e83ded09647de79e36c407b1fa01
2021-08-23 21:21:18 +00:00
"wikimedia/wait-condition-loop": "2.0.2",
Upgrading wikimedia/wrappedstring (v3.2.0 => v4.0.1) Depends-On: Ic26f3a3be1061b77e0af7b8c4c2569f9d070d191 Change-Id: I5a9f97cac52e4e9af612c2130359b017fb7176c1
2021-10-08 23:07:35 +00:00
"wikimedia/wrappedstring": "4.0.1",
Upgrade wikimedia/xmp-reader from 0.9.3 to 0.9.4 Bug: T379435 Change-Id: Ic5068f01dbc3f4295946c066a86a6d958dbc6e9c Depends-On: Iad2909b8df0141ff4ce08f4d6d5b34ab3e9b7f0a (cherry picked from commit 40faa7c13eba78caac0c5c9cf2d0b087966dc5c8)
2024-11-09 00:37:53 +00:00
"wikimedia/xmp-reader": "0.9.4",
Upgrading zordius/lightncandy (v1.2.5 => v1.2.6) Depends-On: Ie300e47f0c1429784a9ee97d99b25e37ea83787a Change-Id: Ic2829a2d1c6d4ba106b162416cedecd7066f2c34
2021-10-08 22:59:23 +00:00
"zordius/lightncandy": "1.2.6"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
"require-dev": {
Upgraded composer/spdx-licenses from 1.5.7 to 1.5.8 Change-Id: I0d27c4af2d16683523673ca9e724430bf2ae02de
2023-12-22 02:57:16 +00:00
"composer/spdx-licenses": "1.5.8",
Update doctrine/dbal from 3.7.2 to 3.8.4 Change-Id: Iac302e94f8dc3323990c4dbfc6c394e6be23755c
2024-05-03 18:21:35 +00:00
"doctrine/dbal": "3.8.4",
Upgraded doctrine/sql-formatter from 1.1.1 to 1.1.3 Change-Id: Ie3b14974422f06153f76ab50150f1f14ff7228af
2023-12-22 02:58:37 +00:00
"doctrine/sql-formatter": "1.1.3",
build: Updating npm dependencies * mocha: 9.2.1 → 9.2.2 * https://github.com/advisories/GHSA-f8q6-p94x-37v3 * recursive-readdir: 2.2.2 → 2.2.3 * https://github.com/advisories/GHSA-f8q6-p94x-37v3 Change-Id: I9643a6d5a6f8136e8f670b2b224daeb3361b7741
2022-10-26 00:25:19 +00:00
"ext-simplexml": "*",
tests: Update giorgiosironi/eris to 0.14.0 So we can also update it in WikibaseLexeme. There’s nothing super important in this release [1] – PHP 8.2 support is nice for local development, I suppose – but mainly I just don’t want us to be stuck on an old version for too long. [1]: https://github.com/giorgiosironi/eris/blob/master/CHANGELOG.md#0140---2023-04-21 Bug: T351383 Change-Id: I5a04487cada95018fcbfeebdcd6f317e4c0415c5
2023-11-20 13:56:31 +00:00
"giorgiosironi/eris": "^0.14.0",
Switch to librarized version of TestingAccessWrapper Replaces \TestingAccessWrapper (defined in core) with \Wikimedia\TestingAccessWrapper (defined in the composer package wikimedia/testing-access-wrapper). See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper for downstream patches. The core version of the class is kept around for a while to avoid circular dependency problems. Bug: T163434 Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
2017-04-19 19:37:35 +00:00
"hamcrest/hamcrest-php": "^2.0",
Update johnkary/phpunit-speedtrap to 4.0 Because I want Daimona's PR #71. I reviewed the diff. Change-Id: I4ecd2a191a7fd023aa82d80a3736b56de39b41f3
2022-01-24 04:22:04 +00:00
"johnkary/phpunit-speedtrap": "^4.0",
Upgrade mediawiki/mediawiki-codesniffer from 44.0.0 to 45.0.0 and composer/semver from v3.4.2 to v3.4.3 Bug: T375310 Depends-On: I7245d5d0dd5ccdfc483c5dc95690b8971a8f0bac Change-Id: I4c0e4eac206035dfbd9d7268fbd895c16957d4da (cherry picked from commit 2869a7e77cea2f4a4f5b712b758a31f40c961924)
2024-10-07 13:26:22 +00:00
"mediawiki/mediawiki-codesniffer": "45.0.0",
build: Upgrade mediawiki/mediawiki-phan-config from 0.13.0 to 0.14.0 manually * Switch out raw Exceptions, mostly for InvalidArgumentExceptions. * Fake exceptions triggered to give Monolog a backtrace are for some reason "traditionally" RuntimeExceptions, instead, so we continue to use that pattern in remaining locations. * Just entirely give up on PostgresResultWrapper's resource vs. object mess. * Drop now-unneeded false positive hits. Change-Id: Id183ab60994cd9c6dc80401d4ce4de0ddf2b3da0
2024-02-08 23:12:50 +00:00
"mediawiki/mediawiki-phan-config": "0.14.0",
Add minus-x Change-Id: If2d1c61e3a6ed6cdad7fb94021f80c2a547f8100
2024-05-04 17:50:57 +00:00
"mediawiki/minus-x": "1.1.3",
composer.json: Updated nikic/php-parser from ^5.3.1 to ^5.5.0 Bug: T379508 Bug: T381291 Change-Id: Ica6a43980cbb07928ac4810fe51aa2f99d8b9bdc (cherry picked from commit 277b3feb2255da425e9340b9512797f93691d5ac)
2025-06-18 09:45:09 +00:00
"nikic/php-parser": "^5.5.0",
build: Updating dependencies composer: * mediawiki/mediawiki-codesniffer: 38.0.0 → 39.0.0 The following sniffs are failing and were disabled: * MediaWiki.PHPUnit.AssertEmpty.AssertEmptyUsed * php-parallel-lint/php-console-highlighter: 0.5 → 1.0.0 * php-parallel-lint/php-parallel-lint: 1.3.1 → 1.3.2 npm: * grunt-banana-checker: 0.9.0 → 0.10.0 * grunt: 1.5.2 → 1.5.3 * karma: 6.3.15 → 6.4.1 * async: 2.6.3 → 2.6.4 * https://github.com/advisories/GHSA-fwr7-v2mv-hh25 * got: 11.8.3 → 11.8.5 * https://github.com/advisories/GHSA-pfrx-2q88-qq97 Change-Id: I1d7bc9c9599b48d2bd837617cad409a31adb362a
2022-10-07 17:35:34 +00:00
"php-parallel-lint/php-console-highlighter": "1.0.0",
build: Update php-parallel-lint/php-parallel-lint to 1.4.0 Bug: T361217 Change-Id: I4d0b643cf4b39fc34a0eededcd0b995af0caabfe
2024-03-29 02:55:30 +00:00
"php-parallel-lint/php-parallel-lint": "1.4.0",
Updated phpunit/phpunit to 9.6.19 Change-Id: I2e38a2ece160f5c4f3e1c4a26003e351567d8350
2024-05-03 19:56:51 +00:00
"phpunit/phpunit": "9.6.19",
debug: Update PsySH 0.12.0 -> 0.12.3 0.12.3 fixes an annoying bug with namespace handling ( https://github.com/bobthecow/psysh/issues/783 ). This has already been applied to mediawiki/vendor in Ie798e8a08ac8064263bcedbd05110f5faac44211. Change-Id: I688da1be1ee33976008e079ec69a9e2df39314dd
2024-04-06 08:15:58 +00:00
"psy/psysh": "^0.12.3",
Update seld/jsonlint from 1.10.1 to 1.10.2 Change-Id: I4e2bd4ba51df2bbb103d3c3c724d8dec88c8dca4
2024-05-03 13:58:40 +00:00
"seld/jsonlint": "1.10.2",
composer: Bump wikimedia/alea to 1.0.0; drop bcp-47-code dev-dependency Parsoid's ParserTest infrastructure uses wikimedia/alea, which is why it appears in core's require-dev, and Parsoid has bumped their dependency to 1.0.0. We already have wikimedia/bcp-47-code in `require`; we don't need it also in `require-dev`. Change-Id: Ia10d7439709a5370214ce5e3b957ec09b759af27
2023-03-10 18:27:41 +00:00
"wikimedia/alea": "1.0.0",
TransformHandler: add test for variant conversion Change-Id: I91acc9b4306a8170be5e4f94377aab764e185807
2022-09-21 08:36:36 +00:00
"wikimedia/langconv": "^0.4.2",
build: Raise TestingAccessWrapper from 2.0.0 to 3.0.0 Breaking change is only dropping PHP 7.2 & 7.3 support, which we already don't support here. Full list of changes (as no 'upstream' changelog): d260476 build: Updating ockcyp/covers-validator to 1.3.1 c5f7bf0 build: Updating mediawiki/mediawiki-codesniffer to 34.0.0 27e4b91 Remove unneeded \ with ReflectionException 52d95d0 build: Updating composer dependencies 4502843 Add tests to cover currently uncovered lines 19c8b76 build: Updating composer dependencies 2ecdc9d build: Cleanup and improve .phpcs.xml 98375ff build: Updating mediawiki/mediawiki-codesniffer to 37.0.0 a4813ea build: Updating composer dependencies b62e9d6 build: Updating composer dependencies 9c5f87e build: Updating composer dependencies 7b31aab [BREAKING CHANGE] Drop PHP 7.2 and PHP 7.3 support 89423ac build: Upgrade PHPUnit from ^8.5 to 9.5.28 f100e7f build: Updating mediawiki/mediawiki-codesniffer to 41.0.0 a06a1e5 tests: Make data provider a static method e3c0ef8 build: add phan 975c15c Add TestingAccessWrapper::construct() to use non-public constructors 975e899 Avoid deprecation warning for static properties Bug: T352789 Bug: T287972 Change-Id: Ie4b93e737d98242fbad33f7b690a2412bdce543d Depends-On: Iff3556dbff2cc1d9333d83f09d21765ee83bf1e9
2023-12-05 18:19:41 +00:00
"wikimedia/testing-access-wrapper": "^3.0.0",
Bump hamcrest-html-matchers to 1.0.0 Change-Id: I260f060e70ca5e3658c629c341faec38899a67cc
2021-04-20 12:41:37 +00:00
"wmde/hamcrest-html-matchers": "^1.0.0"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
build: Don't install symfony/polyfill-* that we require We require ext-ctype and ext-mbstring, so there's no need to install their polyfills. These are just development dependencies, but the less, the better. Change-Id: I437e5e96092de1d372a031f5b69ddefcd19b31d7
2019-01-21 22:22:31 +00:00
"replace": {
"symfony/polyfill-ctype": "1.99",
composer.json: Replace away two symfony-polyfill-intl libraries We require ext-intl, so don't need intl polyfills Change-Id: I33feb82b1e8d62ef9486712ae41909df74982d40
2024-01-25 19:55:11 +00:00
"symfony/polyfill-intl-grapheme": "1.17.1",
"symfony/polyfill-intl-normalizer": "1.17.1",
composer.json: Replace away symfony php polyfills for PHP8/8.1 We know we need 8.1, so we don't need the polyfills Bug: T398269 Change-Id: I022b9c38d52d79a0551732faa6df929b924808ab
2025-07-01 12:40:33 +00:00
"symfony/polyfill-mbstring": "1.99",
"symfony/polyfill-php80": "1.99",
"symfony/polyfill-php81": "1.99"
build: Don't install symfony/polyfill-* that we require We require ext-ctype and ext-mbstring, so there's no need to install their polyfills. These are just development dependencies, but the less, the better. Change-Id: I437e5e96092de1d372a031f5b69ddefcd19b31d7
2019-01-21 22:22:31 +00:00
},
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"suggest": {
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-apcu": "Faster web responses overall.",
composer.json Add ext-bcmath and ext-gmp to suggests One of the two is needed for Temporary Account scrambling. One of the two are needed by GlobalIdGenerator for 32 bit machines. And ext-gmp may be needed for some operations in the trackBlobs maintenance script. Bug: T355003 Follows-Up: I1011a96894fbf0b92d20a96149e68014f53e3c3c Change-Id: Ibcea140e5024b7cee1e63199d0d6f637324206a2
2024-01-13 16:42:00 +00:00
"ext-bcmath": "Increased performance of some operations. Required especially on 32 bit machines. This or ext-gmp are needed for scrambling Temporary Accounts.",
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-curl": "Faster HTTP services, e.g. when using InstantCommons, Swift, or Etcd.",
Add missing php extension ext-exif as suggested Exif has always been a part of our code for a long while, but it seems it never made it into composer.json before Change-Id: I0c3beaf17e123948dd1d918a340e207d9ecfcc19
2023-01-24 22:14:20 +00:00
"ext-exif": "Enable processing of EXIF information in file uploads.",
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-gd": "Enable thumbnails for file uploads.",
composer.json Add ext-bcmath and ext-gmp to suggests One of the two is needed for Temporary Account scrambling. One of the two are needed by GlobalIdGenerator for 32 bit machines. And ext-gmp may be needed for some operations in the trackBlobs maintenance script. Bug: T355003 Follows-Up: I1011a96894fbf0b92d20a96149e68014f53e3c3c Change-Id: Ibcea140e5024b7cee1e63199d0d6f637324206a2
2024-01-13 16:42:00 +00:00
"ext-gmp": "Increased performance of some operations. Required especially on 32 bit machines. This or ext-bcmath are needed for scrambling Temporary Accounts.",
composer.json: Add 5 more ext- to suggests Change-Id: Ib26a5257f38882d7ba977ea3d1c31a9d1b3e3b02
2024-07-31 15:51:08 +00:00
"ext-igbinary": "Enables use of igbinary for serialisation.",
"ext-imagick": "Enables use of imagemagick for image manipulation.",
"ext-memcached": "Enables use of Memcached for caching purposes.",
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-mysqli": "Enable the MySQL and MariaDB database type for MediaWiki.",
"ext-pdo": "Enable the SQLite database type for MediaWiki.",
"ext-pgsql": "Enable the PostgreSQL database type for MediaWiki.",
"ext-posix": "Enable CLI concurrent processing, e.g. for runJobs.php.",
"ext-pcntl": "Enable CLI concurrent processing, e.g. for runJobs.php and rebuildLocalisationCache.php.",
"ext-readline": "Enable CLI history and autocomplete, e.g. for eval.php and other REPLs.",
composer.json: Add 5 more ext- to suggests Change-Id: Ib26a5257f38882d7ba977ea3d1c31a9d1b3e3b02
2024-07-31 15:51:08 +00:00
"ext-redis": "Enables use of Redis for caching purposes.",
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-sockets": "Enable CLI concurrent processing, e.g. for rebuildLocalisationCache.php.",
"ext-wikidiff2": "Faster text difference engine.",
composer.json: Remove two entries from "suggest" * ext-wincache: f89aa38f690674a5 dropped support for this extension because the extension was unmaintained. (And while a new release appeared by the time that change was merged, it is a "beta".) * monolog/monolog: 74aa92ea5ab86a70 moved this from require-dev to require. Change-Id: If8dc10899bcea9e7d8ed43e34308a776bb90b424 (cherry picked from commit a0ebe56dc0190bcc8f084d17407cdabd65836b13)
2024-11-18 05:08:21 +00:00
"ext-zlib": "Enable use of GZIP compression, e.g. for SqlBagOStuff (ParserCache), $wgCompressRevisions, or $wgUseFileCache."
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
},
"autoload": {
composer: Namespace Composer classes Change-Id: I0ae0041ff4929b6791e03cfb8c73f422076125c6
2024-01-13 17:06:28 +00:00
"psr-4": {
"MediaWiki\\Composer\\": "includes/composer"
Remove non namespaced TimestampException Change-Id: I6d5cc227cacc6a24e92002e589e439a3bbd033a7
2018-05-25 12:08:24 +00:00
}
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
},
Add dev dependency on HTML matchers Change-Id: Ic547cbf737221d4ed677e2c23adbbf001047b3c4
2017-02-03 15:09:14 +00:00
"autoload-dev": {
"files": [
"vendor/hamcrest/hamcrest-php/hamcrest/Hamcrest.php",
"vendor/wmde/hamcrest-html-matchers/src/functions.php"
]
},
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
"scripts": {
composer: Use @php instead of php To execute PHP scripts, you can use @php which will automatically resolve to whatever php process is currently being used. Per https://getcomposer.org/doc/articles/scripts.md#executing-php-scripts Change-Id: I8cf1dcc8e926e7dc9215c5fc7d80ea1381b9539c
2023-12-23 21:05:42 +00:00
"mw-install:sqlite": "@php maintenance/run.php install --server=http://localhost:4000 --dbtype sqlite --with-developmentsettings --dbpath cache/ --scriptpath= --pass adminpassword MediaWiki Admin",
composer serve: Disable process timeout Why: - Default process timeout is 300 seconds, which is not helpful when using `composer:serve` What: - Disable the process timeout for `composer:serve` Bug: T347347 Change-Id: I8f2706fdd2e99870530405deca375066dbb7e012
2023-11-24 07:39:37 +00:00
"serve": [
"Composer\\Config::disableProcessTimeout",
composer serve: create and set log directory Why: - New users will appreciate having easy access to MediaWiki logs; in order to make that easier, we need to have a directory to write to and set an environment variable to use that directory What: - Set MW_LOG_DIR for the `serve` command - Add a `logs` directory at the root of MW, and gitignore it - Create the `logs` directory via DevelopmentSettings, if MW_LOG_DIR is defined but does not exist I considered the `cache` directory for the log location as it already exists, but it seemed preferable to not conflate cache and logs. Bug: T347347 Change-Id: Ic3ddb0203df07a0c93df9f431b25a2a5d9ecc407
2023-11-29 09:01:22 +00:00
"@putenv MW_LOG_DIR=logs",
LegacyLogger: Emit to stderr if MW_LOG_STDERR is set Why: - Developers could reasonably expect that `composer serve` would provide logs in the terminal used for serving the app What: - Set an environment variable, MW_LOG_STDERR, and check this in LegacyLogger which is already loaded in DevelopmentSettings for installs using the local development quickstart guidelines. If the env variable is set, and LegacyLogger is already in use for writing to log files, then use error_log() to also write to stderr Bug: T347347 Change-Id: I7ff8ec1664d5ee9ca0487b3ed363b43fe235b738
2023-12-21 08:16:12 +00:00
"@putenv MW_LOG_STDERR=1",
build: Set PHP_CLI_SERVER_WORKERS=8 in composer serve * This way page views and most common user interacts don't involve queued requests by default. * Devtools waterfall charts show realistic latency numbers, instead of making it seem that serving a .jpg is slower than a PHP request, because it happens to be queued behind one, when there are only 3 requests at the same time. * Profilers become more comparable between quickstart, docker, vagrant, beta, and production. * Allow benchmarking with 'ab' out of the box, with at least some concurrency, and in a way that the concurrency is obvious and easy to find (the user ran 'composer serve' and can see WORKERS= setting in the CLI output, as well as in composer.json). * Slightly faster page views, especially interactions like loading VisualEditor where there are 2-3 concurrent API requests. https://www.mediawiki.org/w/index.php?title=Talk%3ALocal_development_quickstart&oldid=6271780#Multiple_workers_for_PHP_server == Why 8 == I believe most CPUs used by contributer's devices have at least 8 cores these days. However, even if they have a 2-core or 4-core machine, I'd much rather requests be handled concurrently by the OS, than forcefully queued in their entirety. Most latency in web apps tends to be blocked on I/O (file, network, database), so there's plenty of oppertunity for CPU sharing. Even in WMF production, we spawn 2x the php-fpm threads as we have CPUs (fpm_workers_multiplier). We could comfortably set this to 16 or 32 as well, but given this is a local server for a single-user, you're realistically not going to actually be able to (naturally) cause more concurrency, short of benchmarking. 8 seems about right as being just above what is normal on a typical pageview, yet short of potential arguments about how much and whether to induce CPU sharing for most people. Bug: T347347 Change-Id: I7d6fbe02e13375d4e95c12165c29469cd0946d34
2023-12-19 16:00:46 +00:00
"@putenv PHP_CLI_SERVER_WORKERS=8",
composer: Use @php instead of php To execute PHP scripts, you can use @php which will automatically resolve to whatever php process is currently being used. Per https://getcomposer.org/doc/articles/scripts.md#executing-php-scripts Change-Id: I8cf1dcc8e926e7dc9215c5fc7d80ea1381b9539c
2023-12-23 21:05:42 +00:00
"@php -S 127.0.0.1:4000"
composer serve: Disable process timeout Why: - Default process timeout is 300 seconds, which is not helpful when using `composer:serve` What: - Disable the process timeout for `composer:serve` Bug: T347347 Change-Id: I8f2706fdd2e99870530405deca375066dbb7e012
2023-11-24 07:39:37 +00:00
],
Exclude node_modules from php lint script Some node modules include PHP scripts, and these files shouldn't be analyzed. This could be improved further by excluding `extensions/*/{node_modules,vendor}`, but I wasn't able to find a way to represent this for php-parallel-lint without listing each directory individually. For comparison, .phpcs.xml has this line to exclude dependencies: <exclude-pattern type="relative">^(\.git|coverage|node_modules|vendor)/*</exclude-pattern> Change-Id: I285eb32f67b71eaf111c9c9cd12f8205ba97eaf3
2022-01-24 22:38:59 +00:00
"lint": "parallel-lint --exclude node_modules --exclude vendor",
Fix 'composer phan' command Use --long-progress-bar, not -p, as the former is clearer, and also more suitable for CI logs. It's also what LibUp would add. Follow-Up: I119224c37a10d2a59068f899baffc6406ea60335 Bug: T253477 Change-Id: Ibd94fb14561e5abef55fdc0a288ace5d50447221
2020-12-23 16:44:17 +00:00
"phan": "phan -d . --long-progress-bar",
phpcs: Use cache flag This will use a temporary cache directory for the files analyzed by phpcs, so that subsequent runs are fast. Bug: T209149 Change-Id: I15967d220c1dbf9f06551cf4a5d01af5ddb739b6
2021-07-06 11:26:55 +00:00
"phpcs": "phpcs -p -s --cache",
build: Updating npm dependencies * ini: 1.3.5 → 1.3.8 * https://npmjs.com/advisories/1589 Additional changes: * Removed useless -p option to phpcbf in "composer fix" command. * Set `root: true` in .eslintrc.json (T206485). Change-Id: I0116578751fd73e43b07c2830adc629f4b85c784
2021-01-03 22:29:28 +00:00
"fix": [
build: Updating npm dependencies * body-parser: 1.19.2 → 1.20.3 * https://github.com/advisories/GHSA-qwcr-r2fm-qrc7 * cookie: 0.4.2 → 0.7.2 * https://github.com/advisories/GHSA-pxg6-pf52-xh8x * engine.io: 6.4.2 → 6.6.2 * https://github.com/advisories/GHSA-pxg6-pf52-xh8x * micromatch: 4.0.7 → 4.0.8 * https://github.com/advisories/GHSA-952p-6rrq-rcjv * socket.io: 4.6.1 → 4.8.1 * https://github.com/advisories/GHSA-25hc-qcg6-38wj * https://github.com/advisories/GHSA-pxg6-pf52-xh8x Additional changes: * Also sorted "composer fix" command to run phpcbf last. Change-Id: I32746ac5ce244ff72de315bf28298ac287d30a14
2024-10-31 00:37:15 +00:00
"minus-x fix .",
"phpcbf"
build: Updating npm dependencies * ini: 1.3.5 → 1.3.8 * https://npmjs.com/advisories/1589 Additional changes: * Removed useless -p option to phpcbf in "composer fix" command. * Set `root: true` in .eslintrc.json (T206485). Change-Id: I0116578751fd73e43b07c2830adc629f4b85c784
2021-01-03 22:29:28 +00:00
],
Stop supporting composer 1.x Bug: T316558 Change-Id: Ie512b43a601502deb50de24e1f3efc45b0223ced
2024-01-13 17:00:37 +00:00
"pre-install-cmd": "MediaWiki\\Composer\\VersionChecker::onEvent",
"pre-update-cmd": "MediaWiki\\Composer\\VersionChecker::onEvent",
composer: Namespace Composer classes Change-Id: I0ae0041ff4929b6791e03cfb8c73f422076125c6
2024-01-13 17:06:28 +00:00
"post-install-cmd": "MediaWiki\\Composer\\ComposerVendorHtaccessCreator::onEvent",
"post-update-cmd": "MediaWiki\\Composer\\ComposerVendorHtaccessCreator::onEvent",
phpunit: Deprecate suite.xml and composer phpunit:entrypoint Leave `composer phpunit` as the main PHPUnit entry point, a single config file (phpunit.xml.dist) and a single bootstrap (bootstrap.php). Deprecate the `composer phpunit:entrypoint`, making it print a deprecation message and then fall back to `composer phpunit`. Deprecate boostrap.integration.php as well. Update the release notes accordingly. Add a temporary PHPUnit extension, only enabled in suite.xml, that prints a deprecation message. Define a new constant in phpunit.php to avoid printing 2 deprecation messages when phpunit.php is used (as it auto-defaults to suite.xml). Add some documentation to bootstrap.php. Bug: T227900 Depends-On: Ie91c9f2882f12fd8ea822529528dd1dd9efe89db Change-Id: If2ffe0522422fd6aadcc08988789d98c2403fc48
2023-07-13 15:31:49 +00:00
"releasenotes": "@phpunit --group ReleaseNotes",
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"test": [
composer.json: Swap `composer foo` for `@foo` Change-Id: Ib65ad97e49ba1b847c19ce1805f32b42382882cd
2021-11-24 16:40:04 +00:00
"@lint .",
Add minus-x Change-Id: If2d1c61e3a6ed6cdad7fb94021f80c2a547f8100
2024-05-04 17:50:57 +00:00
"@phpcs .",
"minus-x check ."
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +00:00
],
composer: Provide `test-some` job for CI Bug: T199403 Change-Id: I901d8d6bfbaeab2fcc3abf528804724f2841f5ec
2021-02-13 02:22:47 +00:00
"test-some": [
composer.json: Swap `composer foo` for `@foo` Change-Id: Ib65ad97e49ba1b847c19ce1805f32b42382882cd
2021-11-24 16:40:04 +00:00
"@lint",
"@phpcs"
composer: Provide `test-some` job for CI Bug: T199403 Change-Id: I901d8d6bfbaeab2fcc3abf528804724f2841f5ec
2021-02-13 02:22:47 +00:00
],
phpunit: Deprecate tests/phpunit/phpunit.php script `composer phpunit:entrypoint` should be used instead. Copy all the setup to a new bootstrap file, with some adjustments for the bootstrap not being in the global scope when PHPUnit loads it. Leave the old script and bootstrap in place (e.g., for CI), but make them print deprecation warnings. Update the composer scripts to use the standard `phpunit` entrypoint. The bootstrap code was copied almost verbatim from the phpunit.php entrypoint to minimize changes. Any improvements can be done in other patches. Bug: T90875 Change-Id: I95a80c44f8d88c3c498efe1ae64008f0ff1eea55
2023-07-02 17:14:27 +00:00
"phpunit": "phpunit",
"phpunit:unit": "@phpunit --colors=always --testsuite=core:unit,extensions:unit,skins:unit",
composer.json: Reference a single phpunit script Make use of `@` reference so that phpunit is invoked from a centrally defined command. Otherwise phpunit:integration defaults to `vendor/bin/phpunit` when `tests/phpunit/phpunit.php` may be desired instead. `composer phpunit:unit` does not use the composer.json defined phpunit command, as it must use `vendor/bin/phpunit` and not `tests/phpunit/phpunit.php`; the latter expects a LocalSettings.php file which is not in place at the time that `composer phpunit:unit` runs in CI. See https://getcomposer.org/doc/articles/scripts.md#referencing-scripts Change-Id: I13f947637060698226b6e5a2b593655798196de0
2022-06-07 10:53:59 +00:00
"phpunit:integration": "@phpunit --colors=always --testsuite=core:integration,extensions:integration,skins:integration",
"phpunit:coverage": "@phpunit --testsuite=core:unit --exclude-group Dump,Broken",
Fix phpunit:coverage-edit Change-Id: I1331b1cc459dbf6a8be591866bdd836f7099e0f1 Follow-Up: I0ae0041ff4929b6791e03cfb8c73f422076125c6
2024-05-04 12:48:43 +00:00
"phpunit:coverage-edit": "MediaWiki\\Composer\\ComposerPhpunitXmlCoverageEdit::onEvent",
composer: add "maintenance" script This allows maintenance scripts to be run using `composer maintenance` instead of `maintenance/run`. Examples: composer maintenance Version composer maintenance shell composer maintenance -- update --quick Change-Id: I256be651793e6cc1ab55f96eeb91e9f7487a7c1b
2024-04-24 13:26:38 +00:00
"phpunit:entrypoint": "@phpunit",
Add `phpunit:prepare-parallel:extensions` command In T361190 and Quibble 1.9.0, we introduced parallel execution of PHPUnit tests to speed up the CI jobs. The existing implementation is purely Python/Quibble, and cannot directly be used by developers locally. With this patch, we re-implement the test splitting logic already implemented in CI as a composer task so that the parallel tests can be run locally. There are a couple of different approaches to running PHPUnit tests in parallel. The different approaches have been discussed at length in T50217. Ideally, we would just install the `paratest` extension and use that to parallelise the execution. Unfortunately we have complex test suites (specifically Parser tests and the Scribunto test suite) that dynamically create tests as they run, which makes it hard for `paratest` to work out which tests will run. To overcome this limitation, we use the `phpunit --list-tests` function to create a list of test classes that would be included in the execution of the test suite, then scan the filesystem for classes named in the `tests-list.xml` output. The classes we find are then collected into smaller groups (`split_group_X`) which we can run in parallel in separate processes. We split into 7-8 groups here, as that experimentally leads to an even spread of the tests and consumes 100% of all cores on a 4-core processor. Because `ParserIntegrationTest.php` is a single test class that generates thousands of integration tests, we put that in its own bucket rather than allocating it round-robin to one of the split buckets. This again helps to keep the buckets roughly the same size. The current implementation only supports splitting the `extensions` test suite. We need to do some more development and testing to support splitting other suites. The new composer command `phpunit:prepare-parallel:extensions` will generate a `phpunit.xml` file with the same contents as `phpunit.xml.dist`, but with the split-group suites added. The result of running all of the split groups should be the same as the result of running the whole test suite. Bug: T365976 Change-Id: I2d841ab236c5367961603bb526319053551bec2e
2024-05-31 12:44:45 +00:00
"phpunit:prepare-parallel:extensions": [
"MediaWiki\\Composer\\PhpUnitSplitter\\PhpUnitXmlManager::listTestsNotice",
Add `phpunit:parallel:extensions` composer command In T361190 and Quibble 1.9.0, we introduced parallel execution of PHPUnit tests to speed up the CI jobs. The existing implementation is purely Python/Quibble, and cannot directly be used by developers locally. With this patch, we re-implement the parallel test execution already implemented in CI as a composer task so that the parallel tests can be run locally. The `phpunit:parallel:extensions` command expects to be run after `phpunit:prepare-parallel:extensions`, and expects to find 8 test suites with the names `split_group_X` (for X in 0 through 7) in the PHPUnit configuration file. 8 here is currently a hard-coded number that corresponds to the number of parallel test executions we need to saturate the CPU of a 4-core developer machine, and experimentally leads to a good speed-up versus the serial execution. When this command runs, it forks to launch 8 parallel processes, each running one of the `split_group_X` suites. The parent process waits for the children to complete, buffers the output, collects the exit statuses, then dumps the buffered output and exits with a non-zero status if any of the child processes failed (i.e. if there were test failures). We introduce `phpunit:prepare-parallel:default` as a complement to `phpunit:prepare-parallel:extensions`, and the two commands `phpunit:parallel:database` and `phpunit:parallel:databaseless`. This creates four possible combinations - two different test suites, and two different test groups. This is a similar setup to that which we have in CI - the Database and non-Database tests are run in separate groups, and some jobs use the `extensions` suite while others just use the default suite. The `phpunit:parallel:...` commands will fail with a helpful message if no `split_group_`s are found in the active PHPUnit configuration. To help test whether the split test runs are really running all the tests in the suite, we generate and store the PHPUnit results cache file. Comparing the results cache files from linear versus parallel runs should tell us if all the tests have been executed. Bug: T365976 Change-Id: If106802f08edd5d4c841bb7970c69b88ab3bb39b
2024-06-04 06:38:55 +00:00
"@phpunit --list-tests-xml=tests-list-extensions.xml --testsuite=extensions",
"MediaWiki\\Composer\\PhpUnitSplitter\\PhpUnitXmlManager::splitTestsListExtensions"
],
"phpunit:prepare-parallel:default": [
"MediaWiki\\Composer\\PhpUnitSplitter\\PhpUnitXmlManager::listTestsNotice",
"@phpunit --list-tests-xml=tests-list-default.xml",
"MediaWiki\\Composer\\PhpUnitSplitter\\PhpUnitXmlManager::splitTestsListDefault"
Add `phpunit:prepare-parallel:extensions` command In T361190 and Quibble 1.9.0, we introduced parallel execution of PHPUnit tests to speed up the CI jobs. The existing implementation is purely Python/Quibble, and cannot directly be used by developers locally. With this patch, we re-implement the test splitting logic already implemented in CI as a composer task so that the parallel tests can be run locally. There are a couple of different approaches to running PHPUnit tests in parallel. The different approaches have been discussed at length in T50217. Ideally, we would just install the `paratest` extension and use that to parallelise the execution. Unfortunately we have complex test suites (specifically Parser tests and the Scribunto test suite) that dynamically create tests as they run, which makes it hard for `paratest` to work out which tests will run. To overcome this limitation, we use the `phpunit --list-tests` function to create a list of test classes that would be included in the execution of the test suite, then scan the filesystem for classes named in the `tests-list.xml` output. The classes we find are then collected into smaller groups (`split_group_X`) which we can run in parallel in separate processes. We split into 7-8 groups here, as that experimentally leads to an even spread of the tests and consumes 100% of all cores on a 4-core processor. Because `ParserIntegrationTest.php` is a single test class that generates thousands of integration tests, we put that in its own bucket rather than allocating it round-robin to one of the split buckets. This again helps to keep the buckets roughly the same size. The current implementation only supports splitting the `extensions` test suite. We need to do some more development and testing to support splitting other suites. The new composer command `phpunit:prepare-parallel:extensions` will generate a `phpunit.xml` file with the same contents as `phpunit.xml.dist`, but with the split-group suites added. The result of running all of the split groups should be the same as the result of running the whole test suite. Bug: T365976 Change-Id: I2d841ab236c5367961603bb526319053551bec2e
2024-05-31 12:44:45 +00:00
],
"phpunit:prepare-parallel:split-file": "MediaWiki\\Composer\\PhpUnitSplitter\\PhpUnitXmlManager::splitTestsCustom",
Add `phpunit:parallel:extensions` composer command In T361190 and Quibble 1.9.0, we introduced parallel execution of PHPUnit tests to speed up the CI jobs. The existing implementation is purely Python/Quibble, and cannot directly be used by developers locally. With this patch, we re-implement the parallel test execution already implemented in CI as a composer task so that the parallel tests can be run locally. The `phpunit:parallel:extensions` command expects to be run after `phpunit:prepare-parallel:extensions`, and expects to find 8 test suites with the names `split_group_X` (for X in 0 through 7) in the PHPUnit configuration file. 8 here is currently a hard-coded number that corresponds to the number of parallel test executions we need to saturate the CPU of a 4-core developer machine, and experimentally leads to a good speed-up versus the serial execution. When this command runs, it forks to launch 8 parallel processes, each running one of the `split_group_X` suites. The parent process waits for the children to complete, buffers the output, collects the exit statuses, then dumps the buffered output and exits with a non-zero status if any of the child processes failed (i.e. if there were test failures). We introduce `phpunit:prepare-parallel:default` as a complement to `phpunit:prepare-parallel:extensions`, and the two commands `phpunit:parallel:database` and `phpunit:parallel:databaseless`. This creates four possible combinations - two different test suites, and two different test groups. This is a similar setup to that which we have in CI - the Database and non-Database tests are run in separate groups, and some jobs use the `extensions` suite while others just use the default suite. The `phpunit:parallel:...` commands will fail with a helpful message if no `split_group_`s are found in the active PHPUnit configuration. To help test whether the split test runs are really running all the tests in the suite, we generate and store the PHPUnit results cache file. Comparing the results cache files from linear versus parallel runs should tell us if all the tests have been executed. Bug: T365976 Change-Id: If106802f08edd5d4c841bb7970c69b88ab3bb39b
2024-06-04 06:38:55 +00:00
"phpunit:parallel:custom-groups": "MediaWiki\\Composer\\ComposerLaunchParallel::launchTestsCustomGroups",
"phpunit:parallel:database": "MediaWiki\\Composer\\ComposerLaunchParallel::launchTestsDatabase",
"phpunit:parallel:databaseless": "MediaWiki\\Composer\\ComposerLaunchParallel::launchTestsDatabaseless",
composer: add "maintenance" script This allows maintenance scripts to be run using `composer maintenance` instead of `maintenance/run`. Examples: composer maintenance Version composer maintenance shell composer maintenance -- update --quick Change-Id: I256be651793e6cc1ab55f96eeb91e9f7487a7c1b
2024-04-24 13:26:38 +00:00
"maintenance": "@php maintenance/run.php"
Set optimize-autoloader: true and prepend-autoloader: false in composer.json Quoting Tim from 240fd31cfa6b in mediawiki/vendor (prepend-autoloader): Composer's autoloader is slow, taking about 63µs per class, whereas MediaWiki's is fast, taking about 7µs per class. This adds up to an overhead of about 13% of CPU time on short requests such as API calls. On those same short requests, MediaWiki's autoloader finds most of the classes. So it makes sense to run it first, before the two Composer autoloaders. So change the config so that composer passes $prepend=false to spl_autoload_register(). optimize-autoloader is also just a good idea in general. Change-Id: I383c72a85eda415da92e8a9253e83b4ed591768b
2014-12-02 17:19:18 +00:00
},
"config": {
composer.json: alphabetize sections Alphabetize the entries in require, require-dev, suggest, scrips and config sections of the composer.json configuration file. Change-Id: Ibcfdc428045581674620e2a552b9b49ab1b24f3d
2015-09-27 05:16:10 +00:00
"optimize-autoloader": true,
composer.json: Add wikimedia/composer-merge-plugin to allow-plugins Bug: T298283 Change-Id: If1ca75740394b807467ba8b139d996adc38378c0
2021-12-23 23:11:52 +00:00
"prepend-autoloader": false,
"allow-plugins": {
Disallow composer/installers plugin in composer.json This package is installed by plenty of extensions, including Wikimedia-deployed ones [1]; if you use the composer merge plugin to manage dependencies, then composer will ask you if composer/installers should be allowed to run code, because the merge plugin doesn’t merge the allow-plugins information. Therefore, explicitly list and disallow the plugin in MediaWiki core, even though we don’t use the package directly. [1]: https://codesearch.wmcloud.org/deployed/?q=composer%2Finstallers&files=^composer\.json%24 Bug: T298283 Change-Id: I29f9fb27b9d38fbb1607a0dc9991548e5a0ee967
2022-07-12 12:30:17 +00:00
"wikimedia/composer-merge-plugin": true,
Allow the `phpcodesniffer-composer-installer` composer plugin From https://github.com/PHPCSStandards/composer-installer: > This composer installer plugin allows for easy installation of PHP_CodeSniffer coding standards (rulesets). It is currently needed to add sniffs from the standards defined in PHPCSExtra, see T349327. Bug: T349327 Change-Id: Ie30bc09b937188db84e9106a843f9d4f31100558
2023-10-19 23:04:34 +00:00
"composer/installers": true,
"dealerdirect/phpcodesniffer-composer-installer": true
composer.json: Add wikimedia/composer-merge-plugin to allow-plugins Bug: T298283 Change-Id: If1ca75740394b807467ba8b139d996adc38378c0
2021-12-23 23:11:52 +00:00
}
Introduce Composer merge plugin Require Composer merge plugin to allow easier local Composer dependency management without composer.json edit conflicts. The configuration provided will merge Composer configuration directives found in a `composer.local.json` config file into those specified by MediaWiki's composer.json file at Composer runtime. Bug: T67188 Change-Id: I66a19d0154191e536aab37a5e183e4505bf3e9be
2014-12-30 23:42:32 +00:00
},
"extra": {
"merge-plugin": {
"include": [
"composer.local.json"
Bump composer-merge-plugin to v1.3.0 Update composer-merge-plugin and enable the new feature of omitting "require-dev" sections from merged files. This will help prevent Composer package conflicts when used with extensions that have dev requirements which are not reconcilable with those of MediaWiki itself. Requires: I7453f68e671b9d519ec3f7dfaa22de6ec8f252e9 Change-Id: I768cf21c6601496e34f2b63199df04cbc0090145
2015-11-06 22:11:35 +00:00
],
"merge-dev": false
Introduce Composer merge plugin Require Composer merge plugin to allow easier local Composer dependency management without composer.json edit conflicts. The configuration provided will merge Composer configuration directives found in a `composer.local.json` config file into those specified by MediaWiki's composer.json file at Composer runtime. Bug: T67188 Change-Id: I66a19d0154191e536aab37a5e183e4505bf3e9be
2014-12-30 23:42:32 +00:00
}
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
}
}
Reference in a new issue Copy permalink