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

167 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/",
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
"irc": "irc://irc.freenode.net/mediawiki",
"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": {
composer.json: add requirement for composer-plugin-api ^1.1 Bug: T266418 Change-Id: If77b1e0f9c3cef81850172551ac8e5c1417008e0
2020-10-26 01:27:19 +00:00
"composer-plugin-api": "^1.1",
Drop composer/semver 1.5.2 Bug: T269068 Change-Id: I4c1eebada36e6f0f6a820eef4d39656d0e1e62c1
2020-12-08 16:37:57 +00:00
"composer/semver": "3.2.4",
Update cssjanus/cssjanus from 1.2.1 to 1.3.0 https://github.com/cssjanus/php-cssjanus/releases/tag/v1.3.0 https://github.com/cssjanus/php-cssjanus/compare/v1.2.1...v1.3.0 Bug: T215746 Change-Id: I352f79f6f34279e669057aee7c2f1570800c8a11 Depends-On: Id8aba2d9e99671a9c45e02b271dbf290a11228d7
2019-05-11 00:20:15 +00:00
"cssjanus/cssjanus": "1.3.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": "*",
Update guzzlehttp/guzzle (7.0.1 => 7.2.0) Change-Id: Icb5b0ab7505270e10d5c5cbebe831331baaea967 Depends-On: Ic4b72718d1cb09ac5368990463dffcd1d25380b4
2020-11-06 02:00:14 +00:00
"guzzlehttp/guzzle": "7.2.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",
Update OOUI to v0.41.1 Release notes: https://gerrit.wikimedia.org/g/oojs/ui/+/v0.41.1/History.md Bug: T262549 Bug: T269474 Bug: T269477 Bug: T270960 Change-Id: I0e05786f57f330683113f08f950837163b57ae8c Depends-On: I6ce57cfbfcc48286ec422b258b7460e213abb903
2021-01-26 23:04:51 +00:00
"oojs/oojs-ui": "0.41.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",
Updating pear/mail_mime (1.10.8 => 1.10.9) Change-Id: I579e2cc6adb272f7769ee1ce6f9215bf46383b3b Depends-On: Ia28744930f213ee7fd272c72fe7974e607534232
2020-07-21 22:57:08 +00:00
"pear/mail_mime": "1.10.9",
Updating pear/net_smtp (1.9.1 => 1.9.2) Depends-On: I18a8adc08086d96e060b5da8e0364009058b9f9f Change-Id: Ibf2659eb6c8eb784b3810f4eb59f9dca75701095
2020-09-18 21:37:04 +00:00
"pear/net_smtp": "1.9.2",
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",
Have ServiceContainer implement PSR-11 Bug: T222410 Change-Id: Ifab2602972ba385a975a0d8279605d2c4802ca9f Depends-On: I5629e287208b2f038753d88d328989ebdc934c0f
2019-06-06 01:12:45 +00:00
"psr/container": "1.0.0",
Updating psr/log (1.1.2 => 1.1.3) Change-Id: Ie0335f689da60679f77a91f94fcc6aacbedec56a Depends-On: I8d8c3deae65b74d2837720a31d0b39b647f70e69
2020-03-25 00:45:08 +00:00
"psr/log": "1.1.3",
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 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",
Update wikimedia/at-ease from 1.2.0 to 2.0.0 https://github.com/wikimedia/at-ease/releases/tag/v2.0.0 https://github.com/wikimedia/at-ease/compare/v1.2.0...v2.0.0 Change-Id: Ia49a156e76d0a4e257e91cc6a51050848bcb9a5e Depends-On: If40364e2590e3c23035838f8ed26c4f69e730602
2019-02-12 01:25:12 +00:00
"wikimedia/at-ease": "2.0.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",
Replace password-blacklist with common-passwords Bug: T254799 Change-Id: Id06788a79af470602a80d9176a66e3303dd5add5 Depends-On: Ie6a0a6f636c17dd358bfa4396dd8d031b248a210
2020-06-11 14:22:09 +00:00
"wikimedia/common-passwords": "0.2.0",
Update wikimedia/composer-merge-plugin from 1.4.0 -> 1.4.1 https://github.com/wikimedia/composer-merge-plugin/releases/tag/v1.4.1 https://github.com/wikimedia/composer-merge-plugin/compare/v1.4.0...v1.4.1 Change-Id: I805516387648ae76a2b22adac6f94c498b69e6a3 Depends-On: I50338e7f64f8eb3ff9e7177f59d93c88e08562d6
2017-07-16 15:34:09 +00:00
"wikimedia/composer-merge-plugin": "1.4.1",
Upgrade wikimedia/html-formatter from 2.0.0 to 2.0.1 Bug: T271575 Change-Id: I9c9a28b06733f58e8a83e37d5be65a6c6d5443e7 Depends-On: Ic708d409b145866cbfd85bc69f630eed491d7941
2021-01-22 19:21:52 +00:00
"wikimedia/html-formatter": "2.0.1",
build: Update wikimedia/ip-set from 2.0.1 to 2.1.0 This release remove use the Wikimedia/quietCall function wrappers in favour of calling Wikimedia\AtEase directly. This is used in WebStart/WebRequest::getIP/ProxyLookup::isConfiguredProxy. Bug: T189966 Depends-On: I31a371d206ac22df4d95c2d72c85b8b2d89722fd Change-Id: Icdf34bde803cdea90ca9f6b730391514d6485618
2019-09-04 16:07:37 +00:00
"wikimedia/ip-set": "2.1.0",
Update wikimedia/ip-utils from 1.0.0 to 3.0.1 Bug: T247212 Bug: T248237 Depends-On: Iaa520a50498c4d1d4514874fbe6f72aa0f76ccb8 Change-Id: I155024341e8e6b13240e37b30c31b95dc83a47e0
2020-11-10 12:06:29 +00:00
"wikimedia/ip-utils": "3.0.1",
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",
resourceloader: Add wikimedia/minify package and remove local copies - JavaScriptMinifier: The public interface for this internal class is ResourceLoader::filter which, except for one caller (minify.php) is indeed consistently used already, no other callers need replacing. - CSSMin: Idem for minification, however, this class has some other method as well, which have a number of internal users, but none outside core. These have all been replaced in this commit. - Remove pear/net_url2 as own dependency as this was only used by CSSMin and recently added there. This is now a dependency of wikimedia/minify instead. This was not part of the public API and no longer mentioned here in composer.json or RELEASE-NOTES. (It remains pinned in mediawiki-vendor, however.) Bug: T273247 Depends-On: Iadff8c2112d5e53bd994ab4882006e8c644a2379 Depends-On: Id3c6dcc0b952a9efe34b3a9ed88b716101a51f87 Depends-On: I589be910f57289fd908b22db87241b0e52da60d4 Change-Id: I8d71fc64aeecdb31db218b02e361ae9bb0d19b48
2021-02-18 04:38:29 +00:00
"wikimedia/minify": "2.1.0",
Upgrade wikimedia/object-factory from 2.1.0 to 3.0.0 Bug: T267074 Change-Id: Ic9cf63249744cd61bbe238c005630fc82db41d41 Depends-On: I2eac3e96eafdb540824bbc3ddc0b6cc1aed76bf2
2020-11-17 01:54:26 +00:00
"wikimedia/object-factory": "3.0.0",
Parser tests: Update TestFileReader to the latest reader from Parsoid This replaces the 'requirements' from parser tests (hooks and functionhooks) with a more flexible 'options' clause to allow additional file-level requirements/options to support running parser tests in multiple modes. (For example, with the legacy parser or in one of two parsoid modes.) Bug: T254181 Depends-On: I636bd1f2c8aee327acbbd1636e2ac76355f1d80e Change-Id: I58373d135c3a804f4ce9967112c338435f5cd4b6
2020-12-11 22:54:06 +00:00
"wikimedia/parsoid": "^0.13.0-a20@alpha",
Update wikimedia/php-session-serializer from v1.0.6 to v1.0.7 Change-Id: Id30bb862bec42e508b3551d39f5980d900ade206 Depends-On: Ia19d237198fd2a0a15db467ec9dd97e98a857e33
2019-02-12 00:40:12 +00:00
"wikimedia/php-session-serializer": "1.0.7",
Update purtle to 1.0.7 Companion vendor change is https://gerrit.wikimedia.org/r/c/420911/ Bug: T185589 Change-Id: Ic3b4e902c212adbd25f7364259e3767d4e1dfb7a
2018-03-21 18:39:55 +00:00
"wikimedia/purtle": "1.0.7",
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/relpath": "2.1.1",
Upgrade wikimedia/utfnormal from 2.0.0 to 3.0.1 (and concomitant remex-html) * wikimedia/remex-html: 2.2.1 -> 2.2.2 Bug: T273338 Depends-On: I25bc11cccc2703b84372615487401e2953f1f591 Change-Id: I146bacc8cda24154d3aa0d5d12f3ba00722a5490
2021-01-30 16:34:17 +00:00
"wikimedia/remex-html": "2.2.2",
RequestTimeout library integration * Add $wgRequestTimeLimit. If it is non-null, it starts a time limit, using Excimer with a fallback to set_time_limit(). * Add pretty formatting of timeout exceptions thrown by the library. Related refactoring. * Expose the library's critical section feature in MediaWikiServices * In Setup.php, call warnIfHeadersSent() before sending session headers. This helped to debug a related issue I had. * In wfTransactionalTimeLimit() use the new library, and respect the existing library time limit if it is larger than $wgTransactionalTimeLimit. Bug: T269326 Depends-On: I6409ad8a5cba775c27b0d5a79d3300c4dac4c91a Change-Id: I2e6f6351c451407c06cc7e20932548f7b62e36b6
2021-01-06 05:23:15 +00:00
"wikimedia/request-timeout": "1.0.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",
Update wikimedia/shellbox to 1.0.3 Bug: T274474 Depends-On: I0740696953b828b295318433388a28d868384f02 Change-Id: I4f429501543382359b5244553ecc8cfaf358d01d
2021-02-11 08:22:27 +00:00
"wikimedia/shellbox": "1.0.3",
Upgrade wikimedia/utfnormal from 2.0.0 to 3.0.1 (and concomitant remex-html) * wikimedia/remex-html: 2.2.1 -> 2.2.2 Bug: T273338 Depends-On: I25bc11cccc2703b84372615487401e2953f1f591 Change-Id: I146bacc8cda24154d3aa0d5d12f3ba00722a5490
2021-01-30 16:34:17 +00:00
"wikimedia/utfnormal": "3.0.1",
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",
Updating wikimedia/wait-condition-loop (v1.0.1 => v2.0.1) Bug: T263341 Change-Id: Idfd093c12ac4d2788b33ebbb92bdb0ef272706cc Depends-On: I54f7f66b0f5a7364653c57cfa985a1093b6ff9bb
2021-02-11 18:24:59 +00:00
"wikimedia/wait-condition-loop": "2.0.1",
Update wikimedia/wrappedstring to v3.2.0 This commit removes two `@phan-suppress` annotations that were false negatives found in Dec 2019 from a Phan upgrade (598c4d7f), which this new release fixes. They have to be removed as Phan detects redundant suppressions. Bug: T246490 Depends-On: Ib2ff7d187c7c28b82b8bef95aafe5bd718b74cc1 Change-Id: If776ce363deda46439a878b707423c581be8177d
2020-04-14 15:26:40 +00:00
"wikimedia/wrappedstring": "3.2.0",
Updating wikimedia/xmp-reader (0.7.0 => 0.8.0) Bug: T271575 Depends-On: I7c3d912df2778680c17c3fd4546a2e5f8c58d0b3 Change-Id: I80ef92e32927a98a61dfddd8ad09828a23dbe6ff
2021-01-27 03:14:15 +00:00
"wikimedia/xmp-reader": "0.8.0",
Updating zordius/lightncandy (v1.2.4 => v1.2.5) https://github.com/zordius/lightncandy/compare/v1.2.4...v1.2.5 Bug: T242980 Change-Id: I5c4efdddc131f20473edc630690a3e3696cee7a9 Depends-On: I047527015bced11a9ce0522dd886aece75825f58
2020-03-08 18:13:48 +00:00
"zordius/lightncandy": "1.2.5"
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.3 to 1.5.4 Change-Id: Iebc5ff9a913a69d1adfe994255e7b4b62683f282
2020-09-12 22:33:38 +00:00
"composer/spdx-licenses": "1.5.4",
Upgrade doctrine/dbal from 2.10.4 to 3.0.0 for PHP 8.0 support Some irritating breaking changes, including dropping PHP 7.2 support and renaming the classes we care about. For now, hack in via || and some back-compatibility class aliases. Bug: T270732 Change-Id: I685f099584d2f0e5fa17f1f4275eab5289c7bfee
2020-12-23 02:24:31 +00:00
"doctrine/dbal": "2.10.4||3.0.0",
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/mediawiki-codesniffer to 35.0.0 Change-Id: Idb413be4b8cba8611afdc022af59810ce1a4531e
2021-01-30 12:51:38 +00:00
"mediawiki/mediawiki-codesniffer": "35.0.0",
build: Upgrade mediawiki-phan-config from 0.10.5 to 0.10.6 Change-Id: I73eaadb7a78a4ce84a5bbff2d48665da807fde9f
2020-12-17 18:14:53 +00:00
"mediawiki/mediawiki-phan-config": "0.10.6",
Updating monolog/monolog (2.1.1 => 2.2.0) https://github.com/Seldaek/monolog/releases/tag/2.2.0 https://github.com/Seldaek/monolog/compare/2.1.1...2.2.0 Bug: T242751 Change-Id: Id0476b855deeddcd5098ef0656c85447b903dc7d Depends-On: I96281449ea91cdea6dff774f16733c46ddb4b241
2021-01-12 09:32:04 +00:00
"monolog/monolog": "~2.2.0",
Updating nikic/php-parser (v4.10.0 => v4.10.2) Change-Id: I2314edd83c9b431eeebc9ebebadcace7c1477c56 Depends-On: Ib0b5b9fb1cfd8c6b3acdfee28cef98c39eb10c47
2020-11-17 20:13:50 +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",
"php-parallel-lint/php-parallel-lint": "1.2.0",
Upgrade to PHPUnit 8 Bug: T192167 Depends-On: I1bdf465ab6d5e400f64e5325bc03bd6d62f319c7 Change-Id: Ia12658554c94497a204b7f65f1a6f7b1fa0310ac
2019-11-21 17:49:05 +00:00
"phpunit/phpunit": "^8.5",
Upgrade pimple/pimple from 3.3.0 to 3.3.1 for PHP 8.0 support Change-Id: I383b0f5d454286c3be2e08318def993dc2d80d39 Depends-On: If242fb4ec6add7a34722e54c460ee187a661455d
2020-12-22 19:54:32 +00:00
"pimple/pimple": "3.3.1",
Updating psy/psysh (v0.10.4 => v0.10.5) Change-Id: If8509f4115a5c9a919234c3433043c2df3f8d8be Depends-On: I8153cf4b5fd38c2c3984087f2d7ffaf543eb1f21
2020-12-08 16:46:02 +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",
Updated wikimedia/avro from 1.8.0 to 1.9.0 Bug: T233165 Depends-On: I070678446f1932d63b9c533b4c5406ad7e69e291 Change-Id: I7658c18a3c6868c12ee453027e9f4b30ee663cd9
2019-09-22 21:30:51 +00:00
"wikimedia/avro": "1.9.0",
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",
Alphasort require-dev in composer.json Change-Id: I5e8d3807cae43e427e6fb3a77b1b636314b3ec10
2019-12-08 23:50:25 +00:00
"wmde/hamcrest-html-matchers": "^0.1.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",
Produce monolog messages through kafka+avro This allows a logging channel to be configured to write directly to kafka. Logs can be serialized either to json blobs or the more compact apache avro format. The Kafka handler for monolog needs a list of one of more kafka servers to query cluster metadata from. This should be able to use any monolog formatter, although some like JsonFormatter require you to disable formatBatch as Kafka protocol would prefer to encode each record independently in the protocol. This requires the nmred/kafka-php library, version >= 1.3.0. Adds a new formatter which serializes to the apache avro format. This is a compact binary format which uses pre- defined schemas. This initial implementation is very simple and takes the plain schemas as a constructor argument. Adds a new option to MonologSpi to wrap handlers in a BufferHandler. This doesn't flush until the request shuts down and prevents any network requests in the logger from adding latency to web requests. Related mediawiki/vendor update: Ibfe4bd2036ae8e998e2973f07bd9a6f057691578 The necessary config is something like: array( 'loggers' => array( 'CirrusSearchRequests' => array( 'handlers' => array( 'kafka' ), ), ), 'handlers' => array( 'kafka' => array( 'factory' => '\\MediaWiki\\Logger\\Monolog\\KafkaHandler::factory', 'args' => array( 'localhost:9092' ), 'formatter' => 'avro', 'buffer' => true, ), ), 'formatters' => array( 'avro' => array( 'class' => '\\MediaWiki\\Logger\\Monolog\\AvroFormatter', 'args' => array( array( 'CirrusSearchRequests' => array( 'type' => 'record', 'name' => 'CirrusSearchRequests' 'fields' => array( ... ) ), ), ), ), ), ) Bug: T106256 Change-Id: I6ee744b3e5306af0bed70811b558a543eed22840
2015-08-04 18:02:47 +00:00
"nmred/kafka-php": "Send debug log events to kafka",
"wikimedia/avro": "Binary serialization format used with 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",
build: Update mediawiki-codesniffer to 0.6.0, add "composer fix" * Fix errors spotted by new release * Introduce "composer fix", which uses phpcbf to automatically fix some errors spotted by phpcs. * Drop $PHPCS_ARGS variable that didn't work on Windows, and add -s flag * Remove rules from phpcs.xml that are now in MW-CS ruleset. Change-Id: I13e2155695918c918b67497ac65b85a03897095e
2016-02-17 10:31:52 +00:00
"phpcs": "phpcs -p -s",
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 lint",
Revert "build: Run minus-x to check for executable files that shouldn't be" This reverts commit bd2a718cf09cc5826d5a1ef27b1fbb21741e4342. Bug: T212766 Change-Id: Ic453d7e672ad6c1e39f33f7efd104483f95f5b89
2019-01-02 10:19:43 +00:00
"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",
"phpunit:coverage-edit": "ComposerPhpunitXmlCoverageEdit::onEvent"
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