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

166 lines
5.1 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: Update issues link to point to bugs.mediawiki.org Change-Id: I67f4403f1797a38bc3f5d7b190d7f84f6fdf457c
2014-12-11 20:54:59 +00:00
"issues": "https://bugs.mediawiki.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 from 3.5.4 to 3.5.5 Change-Id: I7bbc99303b07fe363094ddbe7624aabbc60dafb3 Depends-On: Iec357af3b6c9e1af9802f7fab7f189d06a55737a
2021-09-23 07:30:42 +00:00
"composer/semver": "3.2.5",
Update cssjanus/cssjanus from 2.0.0 to 2.1.0 Depends-On: Iac0b7702b001062495f1e08d055481d3c436161e Change-Id: I259c341ad04fcb13921d0cf2433e0552a8870bad
2021-09-09 19:44:48 +00:00
"cssjanus/cssjanus": "2.1.0",
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.2.0 => 7.4.0) Change-Id: I192f0a3a58b00b6fcac35711ca3fb4b1b23378e3 Depends-On: Icbfe05e17b2e5d31da9de3f61b14b6732c56a32f
2021-11-11 15:31:07 +00:00
"guzzlehttp/guzzle": "7.4.0",
Update liuggio/statsd-php-client to 1.0.18 Depends-On: I81a7d7da30374072c78c51d1a7fe8229cd70d42c Change-Id: Ibf06b3b97eb6002c1ad2666f38764b44fc716ef3
2015-11-23 00:37:33 +00:00
"liuggio/statsd-php-client": "1.0.18",
composer.json: 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.42.1 Release notes: https://gerrit.wikimedia.org/g/oojs/ui/+/v0.42.1/History.md Bug: T283812 Bug: T287329 Bug: T288928 Bug: T289043 Bug: T289043 Bug: T290792 Bug: T290975 Bug: T291142 Bug: T291284 Bug: T293274 Bug: T293635 Depends-On: I0918c0c866147e6a103ce8815b7a36d0463457b7 Change-Id: I717ff53e18e95c72ace1c46b6236cfecb5cd8217
2021-11-04 02:07:45 +00:00
"oojs/oojs-ui": "0.42.1",
Only load PEAR Smtp mailer from vendor/composer, not from `pear` itself Change-Id: I91c42a3eafd079039ddbc17a11ad3c7b6579e3c1
2018-05-18 01:56:00 +00:00
"pear/mail": "1.4.1",
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",
"pear/net_smtp": "1.10.0",
Increase PHP requirement from 7.2.9 to 7.2.22 due to segfault issue Follows 15e0e9bb4, as Parsoid code which can trigger this is reliably is now included in MediaWiki. Bug: T228346 Change-Id: Ia0e9d2b84534e8a03880870e0f4434426b23f47a
2020-02-24 17:54:08 +00:00
"php": ">=7.2.22",
Update psr/container and wikimedia/object-factory - Updating psr/container (1.0.0 => 1.1.1) - Updating wikimedia/object-factory (v3.0.0 => v3.0.2) Change-Id: I6b6057ccde2f5bf55ef1a08d7e95439298323ef2 Depends-On: Ifc6b23a9eafe101b850306325ddf8e102d317294
2021-04-25 18:41:41 +00:00
"psr/container": "1.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",
Add symfony/polyfill-php80 Doing this before REL1_37 ensures that any PHP8.0-isms won't break backports. Bug: T290697 Change-Id: I945a08d219c3d30813ca2f778d097ebd8bb0f129
2021-09-13 21:19:21 +00:00
"symfony/polyfill-php80": "1.23.1",
Upgrade wikimedia/assert from 0.4.0 to 0.5.0 Depends-On: I7704fd5224d26514f0b1a6d41b9d35c07585d389 Change-Id: If9e606ff04ead740757d28c249658c322dba8f8d
2020-02-14 20:29:28 +00:00
"wikimedia/assert": "0.5.0",
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",
Updating wikimedia/base-convert (v2.0.0 => v2.0.1) https://github.com/wikimedia/base-convert/compare/v2.0.0...v2.0.1 Change-Id: I96d67e4edca669c028ce9cdf936ec1c8a4a76711 Depends-On: I4aa14f026a2b406035a33ebe56a76bb7c79a5d43
2020-03-09 10:57:18 +00:00
"wikimedia/base-convert": "2.0.1",
wikimedia/cdb: 1.4.0 => 1.4.1 Updated for I5a7a9f259: stop using wikimedia/assert Change-Id: I8c867eeb3e6612b85db1373e5a25565861174f07
2016-05-30 04:21:00 +00:00
"wikimedia/cdb": "1.4.1",
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",
Updating wikimedia/common-passwords (0.2.0 => v0.3.0) Change-Id: I8e98b8f613a917852561c459ef0aaa805dcc8be5 Depends-On: Idc1ccd82c54c803cfff983ebb115ea1e5b75b545
2021-03-19 17:01:09 +00:00
"wikimedia/common-passwords": "0.3.0",
Updating wikimedia/composer-merge-plugin (v1.4.1 => v2.0.1) Bug: T275824 Change-Id: Ifef6c81c3720137fa2cae296f537f3e164f6e4d1 Depends-On: Ia18240d26f9845d117935c3eb26347e6173e890e
2021-02-24 17:11:10 +00:00
"wikimedia/composer-merge-plugin": "2.0.1",
Upgrade wikimedia/html-formatter from 2.0.1 to 3.0.1 Bug: T276455 Change-Id: I9dfb5d38d6ed5d63aebfe3f395d4f9d1eb23f0e8 Depends-On: I2daeb93bf2523d91ae123727eb9d1b7485dcb61e
2021-03-06 13:04:26 +00:00
"wikimedia/html-formatter": "3.0.1",
Updating wikimedia/ip-set (2.1.0 => 3.0.0) Bug: T271575 Change-Id: I794d1bd10174aadb4680e95f5809c85c51eac353 Depends-On: I8131cbad3cd8609d61d1e957f066f17b61b2e470
2021-03-21 21:31:15 +00:00
"wikimedia/ip-set": "3.0.0",
Updating wikimedia/ip-utils (3.0.1 => 3.0.2) Bug: T271575 Change-Id: Id5f119dceb5ea598913000c7ec8b032b3c753d97 Depends-On: I1a337443e5b3a6eda4e9243b08b96e10c9e2ba8e
2021-03-21 21:30:09 +00:00
"wikimedia/ip-utils": "3.0.2",
Upgrade wikimedia/less.php from 3.0.0 to 3.1.0 Principally PHP 8.0 support, but also a performance fix and a bug fix. Bug: T248925 Change-Id: I0781c8977eb047db599c5fc173cf38f6ee015ae1 Depends-On: I133bdac0bfaeab16e35b40ad959dc34f0b98beb8
2020-12-11 19:41:58 +00:00
"wikimedia/less.php": "3.1.0",
Update wikimedia/minify to 2.2.5 Changes since 2.2.4: * Fix minify CLI to work from within vendor directory. * Remove true/false !0/!1 micro optimisation. (T237042) Depends-On: Id2f2061ac5c7389840b73ad138a91df73a40877f Change-Id: I1f437781dd8f0cea516693a6e15fe3f95a0aa2ad
2021-10-23 01:08:18 +00:00
"wikimedia/minify": "2.2.5",
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",
Update psr/container and wikimedia/object-factory - Updating psr/container (1.0.0 => 1.1.1) - Updating wikimedia/object-factory (v3.0.0 => v3.0.2) Change-Id: I6b6057ccde2f5bf55ef1a08d7e95439298323ef2 Depends-On: Ifc6b23a9eafe101b850306325ddf8e102d317294
2021-04-25 18:41:41 +00:00
"wikimedia/object-factory": "3.0.2",
Bump wikimedia/parsoid to v0.15.0-a1 Depends-On: I98e9bde6adfe6954a98748cc646367992f25a190 Change-Id: I210c66c350de1d310480f65385ce67ded7129792
2021-09-20 22:06:17 +00:00
"wikimedia/parsoid": "^0.15.0-a1@alpha",
Updating wikimedia/php-session-serializer (v1.0.7 => v2.0.0) Bug: T271575 Change-Id: If069704e517f749f3fd7de0f6e801c145e6cfab1 Depends-On: I82ee9e6fc2a684c8891b7be01e62be0ae17c3c58
2021-03-21 21:37:41 +00:00
"wikimedia/php-session-serializer": "2.0.0",
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",
Updating wikimedia/relpath (2.1.1 => 3.0.0) Change-Id: I83339f7ab340bc20667955f3cf1592982f6844ee Depends-On: Ia77ffc78b48d4158691b23b5e09cd7a187a0eb62
2021-08-03 17:20:27 +00:00
"wikimedia/relpath": "3.0.0",
Upgrade RemexHtml to 3.0.0 This is required by Parsoid 0.15.0-a6. I don't need to increment the Parsoid version here since it is not using semantic versioning. The caret will allow upgrades until the Glorious Future of 1.0.0. Depends-On: I72346a431f556555410f6af64bdb10140ea9bd8a Change-Id: Idefebb725444d244252623533b8469214324f931
2021-10-25 00:41:57 +00:00
"wikimedia/remex-html": "3.0.0",
Upgrade RequestTimeout to 1.1.0 Depends-On: I6d42216654c589eae1e41bca58d0916967852d75 Change-Id: I14ddb285dd61b788aa96f88c3a12ce6c8d7fb2c2
2021-03-17 22:32:55 +00:00
"wikimedia/request-timeout": "1.1.0",
Update wikimedia dependencies Updated: * wikimedia/ip-set 1.1.0 -> 1.2.0 * wikimedia/relpath 2.0.0 -> 2.1.1 * wikimedia/running-stat 1.1.0 -> 1.2.1 * wikimedia/wrappedstring 2.2.0 -> 2.3.0 https://github.com/wikimedia/IPSet/compare/1.1.0...1.2.0 https://github.com/wikimedia/relpath/compare/2.0.0...2.1.1 https://github.com/wikimedia/runningstat/compare/v1.1.0...v1.2.1 https://github.com/wikimedia/WrappedString/compare/v2.2.0...v2.3.0 Bug: T182273 Change-Id: I23a734e7a5b9a7ff4d46901a9c5b3b51402687d5 Depends-On: Ib2402f41262549207c8386d74855240ca0d4a54b
2018-01-18 21:15:07 +00:00
"wikimedia/running-stat": "1.2.1",
Update wikimedia/scoped-callback to 3.0.0 Depends-On: Idf3ee1f785104257dec8c6bfead821244184b126 Change-Id: I005575a341d4eda4595dc36537c4f2996e32eb45
2018-11-02 00:16:27 +00:00
"wikimedia/scoped-callback": "3.0.0",
Use wikimedia/services 2.0.1 wikimedia/services is a near identical copy of includes/libs/services. Bug: T211608 Depends-On: Iefde0001648bf665d94f115ff1d83b57d13936a6 Change-Id: I3f004d32682be5d732efb36061733494c0779bac
2020-06-29 21:06:46 +00:00
"wikimedia/services": "2.0.1",
Upgrade to Shellbox 3.0.0 Depends-On: Idfe35c788a84f04a760edb01c0bf48ddc8accb1f Change-Id: Ib5ffeec5bb6b45ea7fb93aec8df4368231188b67
2021-10-22 17:59:49 +00:00
"wikimedia/shellbox": "3.0.0",
Updating wikimedia/utfnormal (3.0.1 => 3.0.2) Bug: T277982 Change-Id: I1258eac600510e111756055a16801ddc3fa0513c Depends-On: I086e247886b51da4250e715bea29888929c44b51
2021-03-20 17:39:06 +00:00
"wikimedia/utfnormal": "3.0.2",
Update ObjectFactory and ConvertibleTimestamp * wikimedia/object-factory -> 2.0.0 * wikimedia/timestamp -> 3.0.0 * wikimedia/xmp-reader -> 0.6.3 Needed for I5c0cc3a8. mediawiki/vendor equivalent is Iea05dc43. Bug: T224729 Bug: T144482 Depends-On: Iea05dc439688871c574c639e617765ae88a75ff7 Change-Id: I6705a8d46f53ef807edab10f8f0cb0eba6b560dc
2019-06-19 17:58:20 +00:00
"wikimedia/timestamp": "3.0.0",
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",
Updating wikimedia/xmp-reader (0.8.0 => 0.8.1) Bug: T271575 Depends-On: If925ee94a6974fda134d8ed100ed3285bf6acfc3 Change-Id: I0a46338e9ad723f0ba8ed0840d412e3f56388cf1
2021-03-21 18:03:42 +00:00
"wikimedia/xmp-reader": "0.8.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": {
Update composer/spdx-licenses from 1.5.4 to 1.5.5 Change-Id: Ia286cae043469ee2b213c5869d096d4cecab7f4f
2021-09-23 07:28:01 +00:00
"composer/spdx-licenses": "1.5.5",
Update doctrine/dbal versions Change-Id: I9af2b53825afc7497af4a474c2940fd7dd841e72
2021-11-08 00:49:47 +00:00
"doctrine/dbal": "2.13.4||3.1.3",
Updating doctrine/sql-formatter (1.1.0 => 1.1.1) Change-Id: Ie0db05062b521a4824e62c6eef407dd224ee0fa1
2020-08-02 23:08:48 +00:00
"doctrine/sql-formatter": "1.1.1",
Install giorgiosironi/eris as require-dev Eris is a porting of QuickCheck and property-based testing tools to the PHP and PHPUnit ecosystem. It is used in WikibaseLexeme to generate inputs for tests cases. These tests are skipped if the library is not present. T188354 / Iba3da2820262ca8a879780ee7848cfc831df28b5 removed the extension-specific phpunit run from composer scripts. Due to the unavailability of eris in core composer, and the fact that the composer merge plugin does not install require-dev of extensions, all eris-based tests have been skipped since (2018-02-17). Change-Id: I3909fb34025d9a9e07ccd6c85b30c34144714d04
2018-08-27 11:24:34 +00:00
"giorgiosironi/eris": "^0.10.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",
Alphasort require-dev in composer.json Change-Id: I5e8d3807cae43e427e6fb3a77b1b636314b3ec10
2019-12-08 23:50:25 +00:00
"johnkary/phpunit-speedtrap": "^3.1",
Bump justinrainbow/json-schema development dependency to ~5.2 https://github.com/justinrainbow/json-schema/compare/3.0.1...5.2.0 https://github.com/justinrainbow/json-schema/releases/tag/4.0.0 https://github.com/justinrainbow/json-schema/releases/tag/4.0.1 https://github.com/justinrainbow/json-schema/releases/tag/4.1.0 https://github.com/justinrainbow/json-schema/releases/tag/5.0.0 https://github.com/justinrainbow/json-schema/releases/tag/5.1.0 https://github.com/justinrainbow/json-schema/releases/tag/5.2.0 Change-Id: I9e3aa67bcf1f4e7b6b0dc831c64df73ce0fea8fe
2017-07-17 17:12:55 +00:00
"justinrainbow/json-schema": "~5.2",
build: Update mediawiki-codesniffer from v37.0.0 to v38.0.0 Change-Id: Iff096d3789b8c261aa47fb41d6f450a3bda7ce6a
2021-10-22 20:43:16 +00:00
"mediawiki/mediawiki-codesniffer": "38.0.0",
build: Update mediawiki/mediawiki-phan-config to 0.11.0 Addition and remove of suppression needs to be done with the version update. Change-Id: I3288b3cefa744b507eadebb67b8ab08c86517c1c
2021-08-28 08:40:44 +00:00
"mediawiki/mediawiki-phan-config": "0.11.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",
Update nmred/kafka-php to v0.1.5 Change-Id: Iab9a32807c8f9e6a4c72566d3742bf0dc99a7d3e Depends-On: Ibb9e988b9e81445641c96075a064090d5ed146ca
2015-12-19 00:59:10 +00:00
"nmred/kafka-php": "0.1.5",
composer: Upgrade php-parallel-lint to 1.2.0 and php-console-highlighter to 0.5 Depends-On: I3003ab0586d129d84a01c9b2e99f07e7dcf19367 Change-Id: I4d23087ea24a80fcefda965b3b47696012ef5bd6
2020-06-04 21:51:37 +00:00
"php-parallel-lint/php-console-highlighter": "0.5",
build: Updating dependencies composer: * php-parallel-lint/php-parallel-lint: 1.3.0 → 1.3.1 npm: * @wdio/mocha-framework: 7.4.6 → 7.13.2 * https://npmjs.com/advisories/5197 (CVE-2021-3807) * nth-check: 2.0.0 → 2.0.1 * https://npmjs.com/advisories/5101 (CVE-2021-3803) * ansi-regex: 5.0.0 → 5.0.1 * https://npmjs.com/advisories/5197 (CVE-2021-3807) Change-Id: I0b17591a4d230192d5c64b68252bb3024ddcedae
2021-10-04 06:38:16 +00:00
"php-parallel-lint/php-parallel-lint": "1.3.1",
Upgrade to PHPUnit 8 Bug: T192167 Depends-On: I1bdf465ab6d5e400f64e5325bc03bd6d62f319c7 Change-Id: Ia12658554c94497a204b7f65f1a6f7b1fa0310ac
2019-11-21 17:49:05 +00:00
"phpunit/phpunit": "^8.5",
composer.json: Relax some constraints for some dev requirements Change-Id: Ife7ddb98e3c1064a4e4e70f119549b2a1394e2d7
2021-10-08 19:21:38 +00:00
"psy/psysh": "^0.10.5",
Upgrade seld/jsonlint from 1.7.1 to 1.8.3 for PHP 8.0 support Change-Id: I1b9142ee5a7c8722fc268e25751e37e26c921b2c
2020-12-22 19:50:35 +00:00
"seld/jsonlint": "1.8.3",
Update symfony/yaml supported versions Keep ~3.4 due to T235403 (romaricdrigon/metayaml 1.1 requires symfony/yaml ~2.3|~3.0) Drop 4.3 because we don't need it Bump ~5.0.5 to ~5.1 Bug: T235403 Change-Id: I9e1960402f90205ffaf89795b112bb7b5cbe4bd7
2020-11-04 02:02:37 +00:00
"symfony/yaml": "~3.4|~5.1",
Updating wikimedia/testing-access-wrapper (1.0.0 => 2.0.0) Bug: T268846 Change-Id: I4f550864687241098b86eb9c5de6895424165985 Depends-On: Ieef3d5af038bc0b0fabe7af94e3f4b1d7afa0b51
2020-11-27 03:06:38 +00:00
"wikimedia/testing-access-wrapper": "~2.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": {
Suggest "apcu" not "apc" in composer.json apc is the pre-PHP 5.5 extension that was partly merged into PHP itself (the opcode caching), and partly split into a separate apcu extension for the userland caching. We want people to install apcu for better performance. Note that we still need to support apc because of HHVM. Change-Id: I5830a66bc86ff321bf9141d2b65eedb4802e404f
2018-09-28 05:26:16 +00:00
"ext-apcu": "Local data cache for greatly improved performance",
composer.json: Make ext-curl a suggested package for MediaWiki core curl is the preferred HTTP implementation as far as I'm a aware and the only implementation used by MultiHttpClient, a requirement for something like VisualEditor Change-Id: I40a015339d4a3f92cfadcd92dfd70425639d0412
2017-03-09 16:26:49 +00:00
"ext-curl": "Improved http communication abilities",
composer.json: Recommend OpenSSL MW wouldn't even log users in without OpenSSL in default configuration. Makes sense to mention it. Change-Id: Ifa68adc09c23eed078d6c5624139da7df208fe99
2019-10-07 23:47:34 +00:00
"ext-openssl": "Cryptographical functions",
Add descriptions for composer.json suggested packages The value for a suggested package is intended to be a description of why the library might be desired. <https://getcomposer.org/doc/04-schema.md#suggest> Change-Id: Ic9e7cc884baf82c493b72ef405cfd5ded810dded
2015-08-14 18:04:47 +00:00
"ext-wikidiff2": "Diff accelerator",
"monolog/monolog": "Flexible debug logging system",
Drop Avro format option for monolog without deprecation Bug: T265967 Change-Id: I1b46df143b71db7cc387d3239a4a4489c1f47c96
2021-03-25 15:26:17 +00:00
"nmred/kafka-php": "Send debug log events to kafka"
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": {
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
"ComposerHookHandler": "includes/composer",
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": {
build: Document a one-line dependency-free pure php install method This has been mentioned and referenced from time to time, but having it defined in composer.json would make it much easier to refer to and make use of without having to worry about the specific parameters. This is essentially the same way that Quibble works currently. Also, simplify the Travis CI setup by using this instead of concerning that configuration with MySQL and Travis' specific way of dealing with that. Usage: # Install with pure PHP and start a server (no Apache/MySQL/..) $ composer mw-install $ composer serve $ open http://localhost:4000 Based on <https://wikitech.wikimedia.org/wiki/Fresnel#Quick_MediaWiki>. Bug: T56856 Change-Id: Ib1f8a86afe48b8f1ae6db733735e81f51d698fc9
2020-04-12 20:42:59 +00:00
"mw-install:sqlite": "php maintenance/install.php --server=http://localhost:4000 --dbtype sqlite --dbpath cache/ --scriptpath '' --pass adminpassword MediaWiki Admin",
"serve": "php -S localhost:4000",
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
"lint": "parallel-lint --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"
],
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
"pre-install-cmd": "ComposerHookHandler::onPreInstall",
"pre-update-cmd": "ComposerHookHandler::onPreUpdate",
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",
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: Make `test` run for the whole repo Scripts that want to test specific files should use the `test-some` command, e.g. `composer test-some path/to/file.php`. Note that the dependency in Quibble must be merged, released, and deployed to CI before this can be merged, lest CI is slowed down massively. Bug: T199403 Depends-On: I383ec29bfa0f051099c12ada19de04552c6dbd97 Change-Id: I58db748ebeea1f370906bb4c026833325c25486c
2021-02-13 02:23:56 +00:00
"composer lint .",
"composer 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 lint",
"composer phpcs"
],
build: Remove redundant 'vendor/bin' prefix from composer commands Follows 214750d8d224. This isn't needed because they run with that directory already in their PATH. Change-Id: I855bbe53c2b5c87afa425b7b6d3ec920c452cc99
2019-07-08 21:59:19 +00:00
"phpunit": "phpunit",
"phpunit:unit": "phpunit --colors=always --testsuite=core:unit,extensions:unit,skins:unit",
"phpunit:integration": "phpunit --colors=always --testsuite=core:integration,extensions:integration,skins:integration",
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
"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:entrypoint": "php tests/phpunit/phpunit.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,
"prepend-autoloader": 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
},
"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