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

192 lines
6.4 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/* Depends-On: I78fdb962ca8b8b88b261410d02be857f6b040c22 Change-Id: I955af0f8d47f1f88457fd267f69a107aef1ebb7d
2022-04-12 22:24:40 +00:00
"composer/semver": "3.3.2",
Upgrading cssjanus/cssjanus (v2.1.0 => v2.1.1) Bug: T326472 Change-Id: Idc374078257bfc9535a57e066a90cf33df48b5b0 Depends-On: I79330cabd3d69647e000fde523e383884f4e9e9a
2023-01-10 02:12:31 +00:00
"cssjanus/cssjanus": "2.1.1",
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": "*",
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": "*",
Upgrading guzzlehttp/guzzle (7.5.3 => 7.7.1) Depends-On: Ib3b0e7a87a8e9880f810f67d3bea0666e3f0a35b Change-Id: I2e557ce5ae10901052fd20d2d89fe757fe863ccf
2023-12-21 22:03:58 +00:00
"guzzlehttp/guzzle": "7.7.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",
composer.json: Promote and pin monolog/monolog to require from require-dev wikimedia/shellbox requires monolog/monolog, making it required in MW Change-Id: I1c1c72e29920509d0ec3726add4920409b824c8b
2021-07-28 15:34:00 +00:00
"monolog/monolog": "2.2.0",
Update OOUI to v0.48.3 Release notes: https://gerrit.wikimedia.org/g/oojs/ui/+/v0.48.3/History.md Bug: T93476 Bug: T231138 Bug: T242107 Bug: T293723 Bug: T332120 Bug: T337808 Bug: T342229 Bug: T350071 Bug: T350436 Depends-On: Ie059fee3ff5d367c03e3a7d4080bef28f2ae0f23 Change-Id: Ia5339c3859fec5869c60ddcfd791930884c7e6ea
2023-12-06 23:19:26 +00:00
"oojs/oojs-ui": "0.48.3",
Updated pear/* Depends-On: I70472f616e881bf910765764fa8f8770bbc104c8 Change-Id: I830994a8e0f71dd0ee8c766b5aa571d194d5a590
2023-12-21 20:22:28 +00:00
"pear/mail": "1.6.0",
Update pear/* - Upgrading pear/mail_mime (1.10.9 => 1.10.11) - Upgrading pear/net_smtp (1.9.2 => 1.10.0) Depends-On: Ib698ef15b6f97ea637aedcc6ef26860c8c4a2cd0 Change-Id: I287e148a9078866a55e5f04693406374d8cca976
2021-10-08 20:50:17 +00:00
"pear/mail_mime": "1.10.11",
Updated pear/* Depends-On: I70472f616e881bf910765764fa8f8770bbc104c8 Change-Id: I830994a8e0f71dd0ee8c766b5aa571d194d5a590
2023-12-21 20:22:28 +00:00
"pear/net_smtp": "1.11.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",
Upgrade symfony/* - Upgrading symfony/polyfill-php80 (v1.27.0 => v1.28.0) - Upgrading symfony/polyfill-php81 (v1.27.0 => v1.28.0) - Upgrading symfony/polyfill-php82 (v1.27.0 => v1.28.0) - Upgrading symfony/yaml (v5.4.17 => v5.4.23) Depends-On: Ibabde73873dcf0de42e78db574652caa59f7c772 Change-Id: I1751d9cda961b34621526f85e6c694c62f305643
2023-10-01 14:38:44 +00:00
"symfony/polyfill-php80": "1.28.0",
"symfony/polyfill-php81": "1.28.0",
"symfony/polyfill-php82": "1.28.0",
Install symfony/polyfill-php83 In line with our other PHP 8.x forward-looking dependencies. Depends-On: I1fa21adbb8c6608b3b16f2bdbc5143b49764816c Change-Id: I6e542b689dd20dd68140f7fc209530a998105945
2023-10-04 16:36:14 +00:00
"symfony/polyfill-php83": "1.28.0",
Updated symfony/yaml from 5.4.23 to 5.4.31 Depends-On: I21edb1e150ae54f5968fc951ed9bce280eb97626 Change-Id: I92f20992836247a55c01cd05220708f83c85e74c
2023-12-21 20:23:15 +00:00
"symfony/yaml": "5.4.31",
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",
Upgrade wikimedia/html-formatter from 3.0.1 to 4.0.3 Bug: T330528 Depends-On: Id785cfd2e00762ca6c1ea80200dd4a3d197640f2 Depends-On: Id785cfd2e00762ca6c1ea80200dd4a3d197640fa Change-Id: I4ec79b22a28223e05c85e2cea29eb36e0ec0e905
2023-02-25 22:42:39 +00:00
"wikimedia/html-formatter": "4.0.3",
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",
Add wikimedia/json-codec 2.2.1 Bug: T346829 Depends-On: I86a846d013a6342ee833d1b1c945c8795f578b55 Change-Id: I6087d896bd9f6a4e7375647253dbe142389b8194
2023-10-03 12:54:07 +00:00
"wikimedia/json-codec": "2.2.1",
ResourceLoader: Update wikimedia/less.php to 4.1.1 Ref https://gerrit.wikimedia.org/g/mediawiki/libs/less.php Ref https://gerrit.wikimedia.org/g/mediawiki/libs/less.php/+/v4.1.1/CHANGES.md Depends-On: I3593451722443bb2cac749efeb0e426f3b2badf1 Change-Id: I6ff583336f048d8f15532142156d6b47e60da801
2023-08-01 22:06:29 +00:00
"wikimedia/less.php": "4.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.19.0-a11 Depends-On: I63a603f91a467a940fd189a0fa0d3e13d3ce907e Change-Id: I11e0001e508d1bb8cb996412495ee8195f7bc69e
2023-12-22 17:43:44 +00:00
"wikimedia/parsoid": "0.19.0-a11",
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 latest 4.0.1 Depends-On: Ifc5d473b48fbcbe1768fbc56264e8a6d81ac5e50 Change-Id: Ib7b538b160ef40227085cb795ed249cff1618eb6
2023-08-29 16:00:27 +00:00
"wikimedia/remex-html": "4.0.1",
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",
Update wikimedia/shellbox to 4.0.0. This in turn allows shellbox to work with wikipeg 3.0.0, which contains fixes for PHP 8.1. Change-Id: Id51365fe13dd2ed641f194e4154776bedc5d59b0
2022-11-10 19:08:33 +00:00
"wikimedia/shellbox": "4.0.0",
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",
Upgraded doctrine/dbal from 3.4.2 to 3.7.2 Change-Id: Ibb69b2bac82da938eda664c0f31fee9714bb6a23
2023-12-22 03:00:14 +00:00
"doctrine/dbal": "3.7.2",
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",
Bump codesniffer to 42.0.0 Most noisily, this enables MediaWiki.Arrays.OneSpaceInlineArray. Change-Id: I8ab11399c67ce7e3ab1b6249b591452774393428
2023-09-27 13:22:44 +00:00
"mediawiki/mediawiki-codesniffer": "42.0.0",
Bump phan to 0.13.0 Change-Id: I57c25d953700ca1cd97cc71ec2a28cbeb9ee875f
2023-09-08 20:42:48 +00:00
"mediawiki/mediawiki-phan-config": "0.13.0",
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",
"php-parallel-lint/php-parallel-lint": "1.3.2",
build: Pin PHPUnit to 9.5.28 like in other repos This way upstream new breaking changes don't break CI, and when we're happy to make an upgrade we have LibraryUpgrader as a bot to make the changes to the 57 repos we currently have that each specify PHPUnit in their composer.json file. Change-Id: I6345f744a678dfb54c191ff5e23a6f5bb5df139f
2023-02-27 14:53:09 +00:00
"phpunit/phpunit": "9.5.28",
Upgraded psy/psysh from ^0.11.1 to ^0.12.0 Depends-On: If338a414dbe6201a598ad0fe0fb0532cc59a8199 Change-Id: Id160dcd0b0b8f2d8db4a5c7c39a582937784a245
2023-12-21 20:37:56 +00:00
"psy/psysh": "^0.12.0",
Upgraded seld/jsonlint from 1.8.3 to 1.10.1 Change-Id: Iea742e7b1453f95a684defd62691150184a3699e
2023-12-22 03:01:34 +00:00
"seld/jsonlint": "1.10.1",
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",
"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.",
"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.",
"ext-mysqli": "Enable the MySQL and MariaDB database type for MediaWiki.",
"ext-openssl": "Encrypt session data (or opt-out via $wgSessionInsecureSecrets).",
"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.",
"ext-sockets": "Enable CLI concurrent processing, e.g. for rebuildLocalisationCache.php.",
"ext-wikidiff2": "Faster text difference engine.",
"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": {
"psr-0": {
Provide command to adjust phpunit.xml for code coverage Our current recommendation for adjusting PHPUnit configuration for extension code coverage reports is to manually modify tests/phpunit/suite.xml. This is cumbersome and annoying, since suite.xml is version controlled. This patch proposes a composer script to simplify editing the (non-version controlled) phpunit.xml config in the root of the MediaWiki repo. It is useful if you are interested in generating code coverage reports based on unit tests only, not integration tests. Usage: composer phpunit:coverage-edit -- extensions/GrowthExperiments When you're done, you can run `rm phpunit.xml` to switch back to the default phpunit.xml.dist. The script will use the default includes/src/maintenance directories, but a future improvement would be to identify the relevant directories via the AutoloadClasses property of extension.json. Another improvement would be to provide an option for passing arbitrary paths in core, in case you are working on tests for a specific class and want to generate coverage reports instantly. We could probably also remove dockerfiles/quibble-coverage/phpunit-suite-edit.py (which inspired this patch) and use composer phpunit:coverage-edit instead. Bug: T100294 Change-Id: Ia0ef41f67ca4a64b0d1ca0ddcee488c29630af0b
2019-07-21 18:34:23 +00:00
"ComposerVendorHtaccessCreator": "includes/composer",
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
"ComposerPhpunitXmlCoverageEdit": "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": {
mw-install:sqlite: Use run.php entrypoint Why: - Calling maintenance scripts directly is deprecated and emits a warning, which would be confusing especially for a new contributor to MediaWiki What: - Use run.php entrypoint for `composer mw-install:sqlite` Bug: T347347 Change-Id: Id0c31b8205c03e8036d0fe1e36f5d01ad7d12867
2023-11-29 11:05:59 +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 serve: Use IPv4 networking for built-in server Why: - IPv4 networking is more intuitive for local development. What: - Use 127.0.0.1 instead of "localhost" for the argument to `php -S`. This means that edits will be assigned to 127.0.0.01 instead of e.g. ::1 Change-Id: I007f7efe260ddea2646fea5cd9d8552575d34c92
2023-11-24 07:55:17 +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": [
"phpcbf"
],
SECURITY: Create a .htaccess in /vendor after composer runs The /vendor directory does not need to be web accessible, and to reduce attack surface, it should not be web accessible. We can use the post-install-cmd and post-update-cmd hooks to create a .htaccess after the user has run "composer install" or "composer update". On the first run of composer, this hook will be invoked twice due to the composer merge plugin. If the htaccess file already exists, this hook won't do anything. Bug: T180237 Change-Id: I2cf6541750c90b5708d7cf5f81b914ae2d9d46d1
2017-11-11 00:05:13 +00:00
"post-install-cmd": "ComposerVendorHtaccessCreator::onEvent",
"post-update-cmd": "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 .",
"@phpcs ."
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",
Add a composer command for the custom PHPUnit entry point This is meant to ease migration from the custom entry point to the standard vendor/bin/phpunit in a fashion that is essentially invisible to any consumer of this command. So after this change is merged we can change everything that uses tests/phpunit/phpunit.php to use this composer shortcut, and then eventually make the shortcut point to vendor/bin/phpunit with the right configuration. Bug: T90875 Change-Id: I2388610cda4fcbe87a4187c04ff624db5fa4d17c
2021-05-22 13:27:12 +00:00
"phpunit:coverage-edit": "ComposerPhpunitXmlCoverageEdit::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
"phpunit:entrypoint": "@phpunit"
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