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

221 lines
8.3 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": {
Update composer/semver to 3.4.2 Bug: T370235 Depends-On: Ic4c091c149c445be3f8e4c2970726af095b82865 Change-Id: Id15a4d180a8381fa21e920c0e184f419e7ffa830
2024-08-11 11:12:00 +00:00
"composer/semver": "3.4.2",
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.7.1 to 7.8.1. Depends-On: I56cb7870fea0591c715ec032fe0f5405ecf97087 Change-Id: Iac56f078b0dce99d59efda1481acc06a7a3718fe
2024-05-03 13:41:59 +00:00
"guzzlehttp/guzzle": "7.8.1",
Upgrading justinrainbow/json-schema (5.2.12 => v5.2.13) Depends-On: I998b2166901c9436f3d06ebca06af21a7d199567 Change-Id: I9df31eb2f3ec25d532891d52668e44ecd4e6858e
2023-10-01 14:39:33 +00:00
"justinrainbow/json-schema": "5.2.13",
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",
Update mck89/peast to 1.16.2 Depends-On: I261354917ddaaa7e452907dd1a0b12558dff081d Bug: T358946 Bug: T359014 Change-Id: I00b6ddb74b0bbae833a5632053f7a7953846bebc
2024-03-05 21:05:23 +00:00
"mck89/peast": "1.16.2",
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.50.4 Release notes: https://gerrit.wikimedia.org/g/oojs/ui/+/v0.50.4/History.md Bug: T369597 Bug: T369666 Depends-On: I23ed96557e0c1b30528fd7c4d81ade8dfd5be80e Change-Id: I384eeead649dfa81c1dacf2fc461a2be515256d5
2024-07-12 00:32:45 +00:00
"oojs/oojs-ui": "0.50.4",
Updated pear/* Depends-On: I70472f616e881bf910765764fa8f8770bbc104c8 Change-Id: I830994a8e0f71dd0ee8c766b5aa571d194d5a590
2023-12-21 20:22:28 +00:00
"pear/mail": "1.6.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",
Drop PHP 7.2 & PHP 7.3 support in MediaWiki master; require 7.4.3 This patch or its equivalent has been landed in REL1_35, REL1_36, REL1_37, and REL1_38 for dropping PHP 7.2, and REL1_39 for dropping PHP 7.3 as well. Now that Wikimedia servers have moved, it's time to do this for real. Bug: T261872 Change-Id: I6627e456447ac6e3094b3bcd9c21753904170f64
2020-08-11 11:06:46 +00:00
"php": ">=7.4.3",
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: Ib79817bb0758cc93487df1d38a82e350e02d9f75 Change-Id: I652cb6c8b5f210e217658f9e6f2ca63a2e33069e
2024-04-05 20:22:20 +00:00
"symfony/polyfill-php80": "1.29.0",
"symfony/polyfill-php81": "1.29.0",
"symfony/polyfill-php82": "1.29.0",
"symfony/polyfill-php83": "1.29.0",
Update symfony/yaml to 5.4.39 Depends-On: I81dafaf5eb02d77491faf5b42320bcda584cce32 Change-Id: I79f6bb8e8f046816ab75bc181a00a990fd323e76
2024-05-03 20:02:21 +00:00
"symfony/yaml": "5.4.39",
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",
Updating wikimedia/at-ease (v2.0.0 => v2.1.0) Bug: T271575 Change-Id: Ia85fb8b46a7796b975d54796f09359a015b31523 Depends-On: I9062a53a2e138cad29b04dd93695c08a1d068283
2021-03-21 21:43:42 +00:00
"wikimedia/at-ease": "2.1.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",
Bump wikimedia/json-codec to 3.0.2 This contains a minor bugfix to the ALLOW_OBJECT hint. Depends-On: Ied49bd4e03d4ae816dc9ddd6791d92355be6304e Change-Id: Ibcedd6c0c9809ccae04bfcb7c5892466b48b56ce
2024-07-22 20:03:17 +00:00
"wikimedia/json-codec": "3.0.2",
ResourceLoader: Update wikimedia/less.php from 5.0.0 to 5.1.1 Depends-On: I878d1b0a5de262b49939c3a5b5b20c52617b35af Change-Id: I174360056f611d07390755f5f605dd0467c545a1
2024-08-07 15:19:45 +00:00
"wikimedia/less.php": "5.1.1",
Update wikimedia/minify from v2.5.1 to v2.7.0 Bug: T351231 Depends-On: I21cf3d06016df3a9f948b6a2bc16c5fb2c135a29 Change-Id: I55017612a1995cc78b4768c31362db1521a53380
2023-11-15 16:26:12 +00:00
"wikimedia/minify": "2.7.0",
Add wikimedia/normalized-exception library Depends-On: I8c3a0431ed3a80bc39f0572ae773bb2782b1bdc8 Change-Id: I1f8ad6a0c5e7d4f68274b40473a6c3d2882c782b
2021-07-02 21:05:23 +00:00
"wikimedia/normalized-exception": "1.0.1",
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",
Bump wikimedia/parsoid to 0.20.0-a17 Bug: T372574 Depends-On: I88dd938e65b22726af4bbb22b14db0c00c76eaeb Change-Id: I2295c2dc5582fe65e62f4624d0a3e64589dc1020
2024-08-19 13:49:22 +00:00
"wikimedia/parsoid": "0.20.0-a17",
Upgrading wikimedia/php-session-serializer (v2.0.0 => v2.0.1) Bug: T287972 Change-Id: I0b72c69faec8a194ced8e0da6a18b3db77daebcd Depends-On: Id83f7612ec5c7851a7f8fb1f0e55737b31c6c35b
2022-07-08 22:35:30 +00:00
"wikimedia/php-session-serializer": "2.0.1",
build: Update wikimedia/purtle from 1.0.7 to 1.0.8 Depends-On: I608c1215b5209c25493c997beb21b58ecf20c7ca Change-Id: Iaeeda4e17cb3b04feb813c3f7590f4cba1a5a7f6
2021-09-14 19:36:56 +00:00
"wikimedia/purtle": "1.0.8",
Updated wikimedia/relpath from 3.0.0 to 4.0.0 Depends-On: I7c19a4924323b33ca00fa352cba925805c5cef94 Change-Id: I3c897660c9cba3d8baa4a6bc320e4b9c0d636bb5
2023-12-21 20:32:19 +00:00
"wikimedia/relpath": "4.0.0",
Update wikimedia/remex-html to 4.1.0 Bug: T342110 Bug: T349310 Depends-On: Id0e9031b551f566a620d4f031d2b801856bdece2 Change-Id: Ifada4a2c65c85ef724e63b726c701176de34a674
2024-03-16 16:11:51 +00:00
"wikimedia/remex-html": "4.1.0",
Upgrading wikimedia/request-timeout (1.1.0 => 1.2.0) Depends-On: I02f29397bad8334d38b6de3f7ac50187f11f98a1 Change-Id: I3deb4d9a4555019620ef9db705caa8a52f5d6d2e
2022-02-10 07:54:19 +00:00
"wikimedia/request-timeout": "1.2.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",
Upgrade wikimedia/scoped-callback and wikimedia/services - Upgrading wikimedia/scoped-callback (v3.0.0 => v4.0.0) - Upgrading wikimedia/services (2.0.1 => 3.0.0) Bug: T303227 Depends-On: I7838b32ba7c7f028cdd2c81fd41150d29b312198 Change-Id: Ib47de56f3192bb087a4876313be5ca9aa2d85df7
2022-07-24 16:28:00 +00:00
"wikimedia/scoped-callback": "4.0.0",
"wikimedia/services": "3.0.0",
Bump wikimedia/(parsoid|shellbox) wikimedia/parsoid to 0.19.0-a21 wikimedia/shellbox to 4.0.2 Depends-On: I691fadecd17f28923de429f0a0f41605a76fe60a Change-Id: I29953fbca5e9a029394192e3721f8310aac49500
2024-03-05 17:04:05 +00:00
"wikimedia/shellbox": "4.0.2",
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",
Upgrading wikimedia/xmp-reader (0.9.0 => 0.9.1) Bug: T314096 Depends-On: I7016f832946871cda90014f68f331ba50cdf32b9 Change-Id: I8c17e88e5dba99713a144fe63c4e9546ee5d64cd
2022-12-16 15:13:48 +00:00
"wikimedia/xmp-reader": "0.9.1",
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",
build: Update mediawiki/mediawiki-codesniffer to 44.0.0 Change-Id: Ic83ac1282b1b0b414450aa69731a9efcc55db665
2024-08-11 11:08:16 +00:00
"mediawiki/mediawiki-codesniffer": "44.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: Relax some constraints for some dev requirements Change-Id: Ife7ddb98e3c1064a4e4e70f119549b2a1394e2d7
2021-10-08 19:21:38 +00:00
"nikic/php-parser": "^4.10.2",
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",
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
"symfony/polyfill-mbstring": "1.99"
},
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: Add 5 more ext- to suggests Change-Id: Ib26a5257f38882d7ba977ea3d1c31a9d1b3e3b02
2024-07-31 15:51:08 +00:00
"ext-wincache": "Enables use of WinCache on Windows.",
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-zlib": "Enable use of GZIP compression, e.g. for SqlBagOStuff (ParserCache), $wgCompressRevisions, or $wgUseFileCache.",
Remove deprecated EventRelayerKafka and KafkaHandler Also remove the unmaintained kafka-php package from the from "suggested" and "dev" composer dependencies, as this is now no longer used. Change-Id: If5668974f417b627df95bce47db18d46fa03327c
2022-03-25 00:06:08 +00:00
"monolog/monolog": "Enable use of MonologSpi ($wgMWLoggerDefaultSpi)."
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": [
Add minus-x Change-Id: If2d1c61e3a6ed6cdad7fb94021f80c2a547f8100
2024-05-04 17:50:57 +00:00
"phpcbf",
"minus-x fix ."
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