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

151 lines
4.7 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",
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
"keywords": ["mediawiki", "wiki"],
"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",
Updating composer/semver (1.5.1 => 1.5.2) Change-Id: I6cf7cb5118c43b04deb03ab880bcdf1522174bc3 Depends-On: I9515918394f307913da89dcba838fb6712b72796
2020-10-29 00:15:04 +00:00
"composer/semver": "1.5.2",
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": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-json": "*",
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": "*",
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.40.4 Release notes: https://gerrit.wikimedia.org/g/oojs/ui/+/v0.40.4/History.md Bug: T47656 Bug: T150983 Bug: T251351 Bug: T259906 Bug: T263737 Depends-On: Icdfb86b95a1d88cf2c10bb783d2498142a610f4c Change-Id: Ia23ac8c26877a34fa30735fe5fe4efe7ceb3cfa8
2020-10-07 23:00:32 +00:00
"oojs/oojs-ui": "0.40.4",
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",
resourceloader: Remove wfExpandUrl() coupling from CSSMin There are three cases in CSSMin::remap where performs path resolution. 1. Absolute local path URLs to full URL. Example: url(/static/foo.png), url(/w/index.php?…), etc. These previously used wfExpandUrl(), which got the server name and protocol directly from $wgServer. We will now use the $remote parameter to get this information instead, which is generally set to something like https://wiki/w/resources/foo, and thus naturally contains the server name and protocol. The resolution is powered by the Net_URL2 library, allowing this to work outside Mediawiki as well. Some tests needed to change because they were calling CSSMin::remap with an incomplete $remote dummy values like "/" or "/w, because the test author (past me) was trying to be clever by not supplying it, knowing MW would ignore it. Now that it is consistently used, like normal calls from ResourceLoader would, the expected values will always be based on http://localhost/w, instead of sometimes the competing $wgServer value of `https://expand.example`. 2. Relative local path to full URL Example: url(foo.png), url(../foo.png), url(bar/foo.png) These were already using $remote. The only change is that they now use Net_URL2 library instead of blind string concatenation. One of the benefits of this is that we will no longer need to call wfRemoveDotSegments() to get rid of things like double slashes or redundant "../" sequences. Previously, thing like "foo//bar" or "foo/../bar" were cleaned up only due to wfRemoveDotSegments(). This is now naturally handled by Net_URL2. 3. Remote URLs Example: url(http://example.org/bar.png), url(//example.org/bar.png) This is generally not used in source code, but gadgets may use this, e.g. for upload.wikimedia.org or cross-wiki imports. Other changes: * One test case used spaces within the URL string in CSS, which the net_url2 library represents with percent-encoding instead. Same thing either way. Bug: T88914 Change-Id: Ibef70cc934c0ee8260a244c51bca9fb88c1c0d88
2020-09-11 21:35:37 +00:00
"pear/net_url2": "2.2.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",
Use wikimedia/cldr-plural-rule-parser Replaces the parser included in MediaWiki with same code in a library. Change-Id: I1d2675466a543269e17faf213aa68d2b7afaf78e
2015-09-24 07:15:49 +00:00
"wikimedia/cldr-plural-rule-parser": "1.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",
Update wikimedia/html-formatter to 2.0.0 Bug: T231160 Depends-On: I98900fb0c6936a47ef6129d69c10c21f8c8f9026 Change-Id: Iec5c57256e43b42709aaea2f660eb1d845b389f1
2020-07-27 17:25:48 +00:00
"wikimedia/html-formatter": "2.0.0",
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",
Use wikimedia/ip-utils 1.0.0 to replace IP class Adjust use in ApiBase. Depends-On: I9a172b2bd922c3a62248545906bd9bdfcac03a43 Change-Id: Ie5485b1df9f3886add943ddcf8b0824e87a7f3e4
2019-12-18 18:45:25 +00:00
"wikimedia/ip-utils": "1.0.0",
Upgrade less.php from 1.8.2 to 3.0.0 (no-op) Number bumps to reflect SemVer environmental requirements breakage (whoops). Change-Id: I736559d6db92a16c97dd18b19611b83daa17f407 Depends-On: Ic855187a2306fd3b3ee268f83909aaae0efd3d06
2020-03-11 23:31:17 +00:00
"wikimedia/less.php": "3.0.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",
Use parser test file parser from Parsoid One (test file) parser to rule them all. Reduce a little bit of redundant code between core and Parsoid by using Parsoid's parser test file parser to run core's parser tests. This should have no effect on users of TestFileReader::read() *except* that Parsoid's test file reader is more strict about bogus lines in the test file, including duplicate test names, and we've removed support for the old v1 format (hard deprecated in 1.35). Next step will be to be able to execute parser tests on extensions using Parsoid's parser as well. Bug: T254181 Depends-On: I8ab4a8c59ed1b6837dba428f96a8ba0084b7fb68 Change-Id: I5acaf82819ae964895a831be4f28c31c77a09e84
2020-07-16 22:23:10 +00:00
"wikimedia/parsoid": "^0.13.0-a4@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",
Update wikimedia/remex-html to v2.2.0 This fixes compatibility issues with PHP 7.4. Bug: T250935 Depends-On: I6bcb443b00295911a12b97830bd67c52c10dc469 Change-Id: I14b42f05781e2ab062e7fc2facea9d064f85e104
2020-04-29 21:29:01 +00:00
"wikimedia/remex-html": "2.2.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/utfnormal to 2.0.0 Bug: T188480 Depends-On: I6dc14850ba4dfb0ba237b68337b6a86768739b5b Change-Id: I5f1fc27d5bb588c15cabb7f1c909c104f6325e96
2018-04-16 07:06:56 +00:00
"wikimedia/utfnormal": "2.0.0",
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",
Use wikimedia/wait-condition-loop Since the WaitConditionLoop class was first introduced in 1.28 (current master), no back-compat alias is added. Bug: T146256 Depends-On: Ia84774d83da79fea1e167fe065c69549981f753b Change-Id: Ibd4f15c87105b8caccbd1f661b74b6efa012b77f
2016-10-01 07:07:19 +00:00
"wikimedia/wait-condition-loop": "1.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",
Bump xmp-reader to 0.7.0 Works around error log spam with files with unparseably large XMP metadata blobs (T242966). Also fixes T230960 with new attribute reading for GPano. Bug: T242966 Bug: T230960 Change-Id: If5b398b24c1795b66e3ebdd630cdecc57595fb2e Depends-On: I6e2496f18b2be4721852d864afae755a0c334ce8
2020-01-16 19:12:26 +00:00
"wikimedia/xmp-reader": "0.7.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",
Updating doctrine/dbal (2.10.2 => 2.10.4) Change-Id: Icf902b1a1772f9c2b78c12e2ae4c7b5196e8ecb0
2020-09-12 22:41:49 +00:00
"doctrine/dbal": "2.10.4",
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: Updating mediawiki/mediawiki-codesniffer to 33.0.0 Change-Id: I4dbe8ce6f130fe6631e6329ba972d1569741e072
2020-11-02 01:02:58 +00:00
"mediawiki/mediawiki-codesniffer": "33.0.0",
build: Updating mediawiki/mediawiki-phan-config to 0.10.3 Change-Id: I145cac62c674b5b10db6d3491a6778038a07d5b4
2020-09-24 08:28:09 +00:00
"mediawiki/mediawiki-phan-config": "0.10.3",
Updating monolog/monolog (1.25.2 => 1.25.3) Change-Id: I1f5e47d7327c718ce5d6cad79734454e9335654a Depends-On: I7bd20dc12c26b6504180ae9cce74c4bfc022d662
2020-01-10 09:31:08 +00:00
"monolog/monolog": "~1.25.3",
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",
Add dev-only dependancy on pimple/pimple Bug: T254053 Change-Id: Idc4d2cee0952a8147d74923fabd46cfaeeee232a Follows-Up: I9ce15591dc40b3d717c203fa973141aa45a2500c
2020-05-30 02:48:22 +00:00
"pimple/pimple": "3.3.0",
Updating psy/psysh (v0.10.3 => v0.10.4) Change-Id: I3d9d55a04e2345fe35aa967675e7fcdc442322e2 Depends-On: I0cef97067a1695653f0509998d0ee9b4ddb659cc
2020-05-07 20:23:28 +00:00
"psy/psysh": "0.10.4",
Alphasort require-dev in composer.json Change-Id: I5e8d3807cae43e427e6fb3a77b1b636314b3ec10
2019-12-08 23:50:25 +00:00
"seld/jsonlint": "1.7.1",
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",
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
"wikimedia/testing-access-wrapper": "~1.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",
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-intl": "ICU integration",
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",
"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": {
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",
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: Bump mediawiki-codesniffer to 31.0.0 Done with `composer fix` and suppressing the rest (i.e. sniffs for global variables, which for core should be suppressed anyway). Additionally, add `-p` to `phpcbf`, as otherwise it just seems stuck. Change-Id: Ide8d6cdd083655891b6d654e78440fbda81ab2bc
2020-05-30 10:36:42 +00:00
"fix": "phpcbf -p",
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
],
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