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

182 lines
6.2 KiB
JSON
Raw Normal View History

Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
{
"name": "mediawiki/core",
"description": "Free software wiki application developed by the Wikimedia Foundation and others",
Set the package type to 'mediawiki-core' Since mediawiki is not a library, the package type should be custom. Bug: T190386 Change-Id: Ic31083427af7f70874ccd8acf34336b0e9a562d4
2018-03-22 05:16:59 +00:00
"type": "mediawiki-core",
build: Updating npm dependencies * ini: 1.3.5 → 1.3.8 * https://npmjs.com/advisories/1589 Additional changes: * Removed useless -p option to phpcbf in "composer fix" command. * Set `root: true` in .eslintrc.json (T206485). Change-Id: I0116578751fd73e43b07c2830adc629f4b85c784
2021-01-03 22:29:28 +00:00
"keywords": [
"mediawiki",
"wiki"
],
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"homepage": "https://www.mediawiki.org/",
"authors": [
{
"name": "MediaWiki Community",
"homepage": "https://www.mediawiki.org/wiki/Special:Version/Credits"
}
],
Use SPDX 3.0 license identifier SPDX released version 3 of their license list (<https://spdx.org/licenses/>), which changed the FSF licenses to explicitly end in -only or -or-later instead of relying on an easy to miss + symbol. Bug: T183858 Change-Id: I4cbb98ea2bbacf46a57401dbba2bdb076fca1d3a
2018-03-06 01:14:07 +00:00
"license": "GPL-2.0-or-later",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"support": {
composer.json: Update issues link to point to bugs.mediawiki.org Change-Id: I67f4403f1797a38bc3f5d7b190d7f84f6fdf457c
2014-12-11 20:54:59 +00:00
"issues": "https://bugs.mediawiki.org/",
Freenode -> Libera per wikimedia moving from freenode to libera Bug: T283247 Change-Id: Iebbb13ac53830a8d77b42bf2954cf80d76d78467
2021-05-20 20:57:48 +00:00
"irc": "irc://irc.libera.chat/mediawiki",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"wiki": "https://www.mediawiki.org/"
},
Add Parsoid as a library dependency As Parsoid (including its integration with core) is still in active development, we are using a '^0.12.0' version constraint for now. This allows us to update Parsoid on both the production cluster and the Parsoid cluster by updating the mediawiki-vendor repository (composer.json/composer.lock/etc) without requiring further weekly changes to core's `composer.json`. We will convert this loose constraint to a standard precise constraint when we branch core for release. This commit just adds parsoid as a library. A follow-on commit (Ie336f69692317d7a714809b42e035fb188e66fc0) then removes the auto- loading of Parsoid from the Parsoid extension. This patch doesn't (yet) create any specific uses of Parsoid from the core codebase, but that is expected to follow rapidly once we work through this initial deploy/release process hurdle. Bug: T213494 Bug: T239660 Bug: T240055 Depends-On: I4c0367d6424513767751a2fc1dbe882250bef242 Change-Id: I8b3d3591b9a4f2a48ac83e1d242755c43b223aba
2020-02-13 17:03:07 +00:00
"prefer-stable": true,
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"require": {
Update composer/* Depends-On: I78fdb962ca8b8b88b261410d02be857f6b040c22 Change-Id: I955af0f8d47f1f88457fd267f69a107aef1ebb7d
2022-04-12 22:24:40 +00:00
"composer/semver": "3.3.2",
Update cssjanus/cssjanus from 2.0.0 to 2.1.0 Depends-On: Iac0b7702b001062495f1e08d055481d3c436161e Change-Id: I259c341ad04fcb13921d0cf2433e0552a8870bad
2021-09-09 19:44:48 +00:00
"cssjanus/cssjanus": "2.1.0",
composer.json: Add ext-calendar to require Used by HistoryAction Bug: T302540 Change-Id: I8e77efa1192a3c5b61c36a674d991389e6aba8cb
2022-02-25 12:41:42 +00:00
"ext-calendar": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-ctype": "*",
Add ext-dom to composer.json In most cases it's packaged as part of the php xml extension but there's likely some OS that maybe package it separately.... Shouldn't cause any harm being here Change-Id: I6c8a40a06314e7e4eb3fe83448a2a071e8203554
2019-07-30 20:17:16 +00:00
"ext-dom": "*",
composer.json, require ext-fileinfo PHPVersionCheck requires fileinfo be installed for mime_content_type Change-Id: Iea7d2c7842c770e77c05265d4f4b08b17f9ab71f
2018-09-24 08:25:53 +00:00
"ext-fileinfo": "*",
Require ext-iconv and suggest ext-intl in composer.json Since iconv is required, per running install.php, and intl is recommended. Bug: T90439 Change-Id: I70f6ce9d8d71f8abd3800bbe00aa0f754ce297a2
2015-02-23 15:03:24 +00:00
"ext-iconv": "*",
Mention new required php extension intl This requirement was introduced in: Ic721b9a91e78e4ef07040339d1006b7a90a910c0 Bug: T267669 Change-Id: Iacadf9d4afdaa58e2c03fa50b04aa40a7d668dd8
2020-11-10 17:53:48 +00:00
"ext-intl": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-json": "*",
composer.json: Add ext-libxml and ext-xmlreader to requires Change-Id: I1c82ec4f2b521ff9dc2d4604cf1007847f32f7de
2020-12-27 16:04:42 +00:00
"ext-libxml": "*",
Kill mbstring fallbacks In the age when we require PHP 5.5, pretending that mbstring emulation is not slow and silly is silly. Bug: T129435 Change-Id: Ic8235c9da9a926df63ec7388900c44eab454eebe
2016-01-29 19:42:44 +00:00
"ext-mbstring": "*",
Explicitly require all the required PHP extensions Change-Id: I2bca4ece0c49c3f4f802d3f8f543882ebd14d445
2016-04-06 23:30:41 +00:00
"ext-xml": "*",
composer.json: Add ext-libxml and ext-xmlreader to requires Change-Id: I1c82ec4f2b521ff9dc2d4604cf1007847f32f7de
2020-12-27 16:04:42 +00:00
"ext-xmlreader": "*",
Update "guzzlehttp/guzzle" to version 7.4.5 Bug: T311384 Depends-On: If511b71eabc4c204ff72d2e9b0024c8aab180ad0 Change-Id: Ie4879a8daf92aca2c7e7340b5f2c9f7f67636384
2022-06-27 08:34:49 +00:00
"guzzlehttp/guzzle": "7.4.5",
SettingsBuilder: add ability to validate config against schema Not yet sure if config validation makes sense in production, possibly before we write into cache we can validate, and then trust that the cached values are all valid. This patch just adds ability to validate the configuration. "justinrainbow/json-schema" is already a transitive dependency and is already in vendor. Change-Id: Ib039c897a36a7e1911309fd29514657042b1b139
2021-11-16 20:41:38 +00:00
"justinrainbow/json-schema": "5.2.11",
Update liuggio/statsd-php-client to 1.0.18 Depends-On: I81a7d7da30374072c78c51d1a7fe8229cd70d42c Change-Id: Ibf06b3b97eb6002c1ad2666f38764b44fc716ef3
2015-11-23 00:37:33 +00:00
"liuggio/statsd-php-client": "1.0.18",
composer.json: Promote and pin monolog/monolog to require from require-dev wikimedia/shellbox requires monolog/monolog, making it required in MW Change-Id: I1c1c72e29920509d0ec3726add4920409b824c8b
2021-07-28 15:34:00 +00:00
"monolog/monolog": "2.2.0",
Update OOUI dependency in composer.json Follow-Up: I51764415d8a221b0146922c1b9041ba0d8711326 Change-Id: I3f1d96fcce37e17bba2a4132ce0bf95351c2b6ab
2022-05-17 19:27:01 +00:00
"oojs/oojs-ui": "0.44.0",
Only load PEAR Smtp mailer from vendor/composer, not from `pear` itself Change-Id: I91c42a3eafd079039ddbc17a11ad3c7b6579e3c1
2018-05-18 01:56:00 +00:00
"pear/mail": "1.4.1",
Update pear/* - Upgrading pear/mail_mime (1.10.9 => 1.10.11) - Upgrading pear/net_smtp (1.9.2 => 1.10.0) Depends-On: Ib698ef15b6f97ea637aedcc6ef26860c8c4a2cd0 Change-Id: I287e148a9078866a55e5f04693406374d8cca976
2021-10-08 20:50:17 +00:00
"pear/mail_mime": "1.10.11",
"pear/net_smtp": "1.10.0",
Revert "objectcache: avoid using heavily time-drifted microtime() values in WAN cache" I think this is no longer necessary since PHP commit 65067dff01 [1], first included in PHP 7.2.21, 7.3.8, and in 7.4 since the beginning of that series. That commit fixed the discrepancy between time() and microtime() by making time() use gettimeofday() like microtime() already did (and still does). The PHP requirement in composer.json is tweaked to ensure no PHP 7.3 version without the fix is used; note that supported release branches already require >=7.3.19, and the 7.2 requirement is unchanged. This reverts commit d2c2bf6553c07ea6dd089efd1c7ba62826eea009. [1]: https://github.com/php/php-src/commit/65067dff01fc3a46861ddfe0fe6d3e556460c146 Change-Id: I8bfe0dceb809d0f63a2e9cc767ace9235d5f5246
2022-07-06 10:31:04 +00:00
"php": "~7.2.22 || >=7.3.8",
Update psr/container and wikimedia/object-factory - Updating psr/container (1.0.0 => 1.1.1) - Updating wikimedia/object-factory (v3.0.0 => v3.0.2) Change-Id: I6b6057ccde2f5bf55ef1a08d7e95439298323ef2 Depends-On: Ifc6b23a9eafe101b850306325ddf8e102d317294
2021-04-25 18:41:41 +00:00
"psr/container": "1.1.1",
Upgrading psr/log (1.1.3 => 1.1.4) Change-Id: If11d0081355eb9caa157fb92389d92ac65b27d4e Depends-On: I5c4006f5747075a92a78900606e196d33c6d9a8f
2021-10-08 19:36:55 +00:00
"psr/log": "1.1.4",
WebRequest & RequestFromGlobals: get HTTP headers in one way apache_request_headers() is a vendor-specific function - it got used when present and alternative code paths were exercised otherwise. These preserved certain "special" headers, e.g. Content-Type, only inconsistently. The function getallheaders() is an alias[1] for apache_request_headers() on systems where the latter is present. Alternatively, there is a polyfill (ralouphie/getallheaders) which is already installed in mediawiki-vendor[2] (by virtue of guzzle). Using getallheaders() exclusively, will make sure these "special" headers are consistently available alongside their "regular"[3] peers and helps MediaWiki code focus on its domain. The dependency to ralouphie/getallheaders is made explicit in the same version in which it is currently locked in mediawiki-vendor[4]. This surfaced because the deprecation warning for API POST requests without a Content-Type header, introduced in bba1a0f, appeared in my development system (somewhat dated addshore/mediawiki-docker-dev/) even though the client did a fine job. Interesting implementation detail: While WebRequest keeps track of headers using keys in all upper case, REST RequestFromGlobals does so in all lower case - but both use retrieval logic complementary to their respective approach however. In case of REST RequestFromGlobals this is encapsulated inside of HeaderContainer (setting and retrieving), while WebRequest does all of this by itself. Cf. [5] and [6] [1]: https://www.php.net/manual/en/function.getallheaders.php [2]: https://github.com/wikimedia/mediawiki-vendor/tree/8f2967d/ralouphie/getallheaders [3]: https://www.php.net/manual/en/reserved.variables.server.php#110763 [4]: https://github.com/wikimedia/mediawiki-vendor/blob/8f2967d/composer.lock#L3250 [5]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 [6]: https://www.php.net/manual/en/function.apache-request-headers.php#124236 Bug: T245535 Change-Id: Iba52f152e15928473b729a2588c2462e76e85634
2020-03-18 08:49:15 +00:00
"ralouphie/getallheaders": "3.0.3",
Update symfony/* Change-Id: Id169b0f0fa93756c4e44b18e31221f8a41d9426d Depends-On: I44059e311286f3d2ac244f497f1e945ab97c56f4
2022-06-26 18:30:25 +00:00
"symfony/polyfill-php73": "1.26.0",
"symfony/polyfill-php80": "1.26.0",
"symfony/yaml": "5.4.10",
Update wikimedia/assert from 0.5.0 to 0.5.1 All libraries and extensions require ^0.5.0 so this should Just Work™. Bug: T287972 Depends-On: I38ff3873df866cd896c9028dc6277ac7aac8a932 Change-Id: I0689e447d7b603a347869aa442a58602f45b2647
2021-12-21 12:11:36 +00:00
"wikimedia/assert": "0.5.1",
Updating wikimedia/at-ease (v2.0.0 => v2.1.0) Bug: T271575 Change-Id: Ia85fb8b46a7796b975d54796f09359a015b31523 Depends-On: I9062a53a2e138cad29b04dd93695c08a1d068283
2021-03-21 21:43:42 +00:00
"wikimedia/at-ease": "2.1.0",
Upgrading wikimedia/base-convert (v2.0.1 => v2.0.2) Bug: T287972 Change-Id: I8458f98ec4b47369d53e8d2a42fb0cd24461b24c Depends-On: Ib90bff33eaa15714bcc6659456ab0c24cf13e71d
2022-07-08 22:31:49 +00:00
"wikimedia/base-convert": "2.0.2",
Update wikimedia/cdb to 2.0.0 Also, re-alpha-sort the lists of external libraries in the release notes file. Bug: T287972 Depends-On: Ib55a7fc8968ec7e951d4e4d160db0601aaff74ea Change-Id: If9fd7efd0f232a567204fee0b7b093f6edacd456
2022-01-04 14:24:43 +00:00
"wikimedia/cdb": "2.0.0",
Updating wikimedia/cldr-plural-rule-parser (v1.0.0 => v2.0.0) Bug: T263341 Change-Id: I27405756c5b6733c05ec0edd7cbc8239de20f05c Depends-On: Ic39d29d0579404fd9e4bedf2e2142c8ebe4a3902
2021-02-12 01:01:34 +00:00
"wikimedia/cldr-plural-rule-parser": "2.0.0",
Upgrading wikimedia/common-passwords (v0.3.0 => v0.4.0) To be backported... Change-Id: Ibe55fe9369bfff6b391a1fa47e9e75bce250f03b Depends-On: I26d3c0307929745c58e87f9da68556e3933c00f6
2022-06-29 23:39:16 +00:00
"wikimedia/common-passwords": "0.4.0",
Updating wikimedia/composer-merge-plugin (v1.4.1 => v2.0.1) Bug: T275824 Change-Id: Ifef6c81c3720137fa2cae296f537f3e164f6e4d1 Depends-On: Ia18240d26f9845d117935c3eb26347e6173e890e
2021-02-24 17:11:10 +00:00
"wikimedia/composer-merge-plugin": "2.0.1",
Upgrade wikimedia/html-formatter from 2.0.1 to 3.0.1 Bug: T276455 Change-Id: I9dfb5d38d6ed5d63aebfe3f395d4f9d1eb23f0e8 Depends-On: I2daeb93bf2523d91ae123727eb9d1b7485dcb61e
2021-03-06 13:04:26 +00:00
"wikimedia/html-formatter": "3.0.1",
Upgrading wikimedia/ip-set (3.0.0 => 3.1.0) Change-Id: I81d84c3158b58374233f6488815af6cbfbc8a357 Depends-On: I6c5e738f6bd094b3ef75cb1e250d12856bdbaae8
2022-06-05 17:11:44 +00:00
"wikimedia/ip-set": "3.1.0",
Upgrading wikimedia/ip-utils (3.0.2 => 4.0.0) Change-Id: Ica51e282bf6832ff10b1a41b02c15826da757891 Depends-On: I58cbe3a1bf9c611a3c72aaf07efee970de2ecf69
2022-02-01 16:56:20 +00:00
"wikimedia/ip-utils": "4.0.0",
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: Update wikimedia/minify to 2.3.0 Bug: T303827 Depends-On: Iab346c62b101411bb2315008a8d07b75c4ea5237 Change-Id: Ie8179c9aca5ac5b0a0c4ea2dc96abb7e2a16ec95
2022-04-25 14:20:43 +00:00
"wikimedia/minify": "2.3.0",
Add wikimedia/normalized-exception library Depends-On: I8c3a0431ed3a80bc39f0572ae773bb2782b1bdc8 Change-Id: I1f8ad6a0c5e7d4f68274b40473a6c3d2882c782b
2021-07-02 21:05:23 +00:00
"wikimedia/normalized-exception": "1.0.1",
Update wikimedia/object-factory to 4.0.0 Depends-On: Idd105bc0937acf71935d82549783cd3bcd5f53e3 Change-Id: Ie9f434d36b7da629a6357f1fb00e908f28fa0bca
2022-03-14 16:28:08 +00:00
"wikimedia/object-factory": "4.0.0",
Bump wikimedia/parsoid to 0.16.0 for MW 1.39 Depends-On: I84fe739494237a2e6de24a4864d652f3e27265f7 Change-Id: Ic403cac3bad87a64686257d06f3fb6cc558de310
2022-03-21 21:42:05 +00:00
"wikimedia/parsoid": "^0.16.0-a1@alpha",
Upgrading wikimedia/php-session-serializer (v2.0.0 => v2.0.1) Bug: T287972 Change-Id: I0b72c69faec8a194ced8e0da6a18b3db77daebcd Depends-On: Id83f7612ec5c7851a7f8fb1f0e55737b31c6c35b
2022-07-08 22:35:30 +00:00
"wikimedia/php-session-serializer": "2.0.1",
build: Update wikimedia/purtle from 1.0.7 to 1.0.8 Depends-On: I608c1215b5209c25493c997beb21b58ecf20c7ca Change-Id: Iaeeda4e17cb3b04feb813c3f7590f4cba1a5a7f6
2021-09-14 19:36:56 +00:00
"wikimedia/purtle": "1.0.8",
Updating wikimedia/relpath (2.1.1 => 3.0.0) Change-Id: I83339f7ab340bc20667955f3cf1592982f6844ee Depends-On: Ia77ffc78b48d4158691b23b5e09cd7a187a0eb62
2021-08-03 17:20:27 +00:00
"wikimedia/relpath": "3.0.0",
Upgrading wikimedia/remex-html (3.0.1 => 3.0.2) To be backported to REL1_38, so no RELEASE-NOTES Change-Id: I1fca338ca4383daf860149d88ed83dcc13cbd45f Depends-On: Ib1931860b536e99a7efc8f072a3e2a6f4fe83e26
2022-06-27 22:29:03 +00:00
"wikimedia/remex-html": "3.0.2",
Upgrading wikimedia/request-timeout (1.1.0 => 1.2.0) Depends-On: I02f29397bad8334d38b6de3f7ac50187f11f98a1 Change-Id: I3deb4d9a4555019620ef9db705caa8a52f5d6d2e
2022-02-10 07:54:19 +00:00
"wikimedia/request-timeout": "1.2.0",
Upgrading wikimedia/running-stat (v1.2.1 => v2.0.0) Bug: T287972 Change-Id: I8573b18909ea74aec04b7ae6c5dc5cb4f3f234ac Depends-On: I353c10547d7161caaba246f169adfa91a4a6cd77
2022-07-08 22:40:56 +00:00
"wikimedia/running-stat": "2.0.0",
Update wikimedia/scoped-callback to 3.0.0 Depends-On: Idf3ee1f785104257dec8c6bfead821244184b126 Change-Id: I005575a341d4eda4595dc36537c4f2996e32eb45
2018-11-02 00:16:27 +00:00
"wikimedia/scoped-callback": "3.0.0",
Use wikimedia/services 2.0.1 wikimedia/services is a near identical copy of includes/libs/services. Bug: T211608 Depends-On: Iefde0001648bf665d94f115ff1d83b57d13936a6 Change-Id: I3f004d32682be5d732efb36061733494c0779bac
2020-06-29 21:06:46 +00:00
"wikimedia/services": "2.0.1",
Upgrade to Shellbox 3.0.0 Depends-On: Idfe35c788a84f04a760edb01c0bf48ddc8accb1f Change-Id: Ib5ffeec5bb6b45ea7fb93aec8df4368231188b67
2021-10-22 17:59:49 +00:00
"wikimedia/shellbox": "3.0.0",
Updating wikimedia/utfnormal (3.0.1 => 3.0.2) Bug: T277982 Change-Id: I1258eac600510e111756055a16801ddc3fa0513c Depends-On: I086e247886b51da4250e715bea29888929c44b51
2021-03-20 17:39:06 +00:00
"wikimedia/utfnormal": "3.0.2",
Upgrading wikimedia/timestamp (v3.0.0 => v4.0.0) Change-Id: Ic80ba1facc75bf197d68e705d32cc5530f5d7136 Depends-On: I8a94c0e2e3dd819f8d35f702a5615429e065ed1f
2022-06-26 18:40:33 +00:00
"wikimedia/timestamp": "4.0.0",
Update wikimedia/wait-condition-loop from 2.0.1 to 2.0.2 Bug: T289176 Bug: T287972 Depends-On: I009fde18d039ede388a758021651961f0c0f13b0 Change-Id: I9bf513183672e83ded09647de79e36c407b1fa01
2021-08-23 21:21:18 +00:00
"wikimedia/wait-condition-loop": "2.0.2",
Upgrading wikimedia/wrappedstring (v3.2.0 => v4.0.1) Depends-On: Ic26f3a3be1061b77e0af7b8c4c2569f9d070d191 Change-Id: I5a9f97cac52e4e9af612c2130359b017fb7176c1
2021-10-08 23:07:35 +00:00
"wikimedia/wrappedstring": "4.0.1",
Upgrading wikimedia/xmp-reader (0.8.2 => 0.8.3) Change-Id: I0fec3af9a16c315d48209901c88860c1395f8642 Depends-On: Ib4fb8570a84f2621f8c1a607072f86c861cf5f62
2022-07-10 02:26:14 +00:00
"wikimedia/xmp-reader": "0.8.3",
Upgrading zordius/lightncandy (v1.2.5 => v1.2.6) Depends-On: Ie300e47f0c1429784a9ee97d99b25e37ea83787a Change-Id: Ic2829a2d1c6d4ba106b162416cedecd7066f2c34
2021-10-08 22:59:23 +00:00
"zordius/lightncandy": "1.2.6"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
"require-dev": {
composer.json: Add ext-simplexml to require-dev Used by ExportTest and RandomImageGenerator Bug: T302540 Change-Id: I1ebb975905687174bae753b7165c58653c715833
2022-02-25 12:45:04 +00:00
"ext-simplexml": "*",
Update composer/* Depends-On: I78fdb962ca8b8b88b261410d02be857f6b040c22 Change-Id: I955af0f8d47f1f88457fd267f69a107aef1ebb7d
2022-04-12 22:24:40 +00:00
"composer/spdx-licenses": "1.5.6",
Update doctrine/dbal versions doctrine/dbal 3.1.3 suffered from CVE-2021-43608 Change-Id: Ia58cfac87271d75530cac29cc4966833fbe00480
2022-01-04 22:41:44 +00:00
"doctrine/dbal": "2.13.6||3.1.5",
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",
Update johnkary/phpunit-speedtrap to 4.0 Because I want Daimona's PR #71. I reviewed the diff. Change-Id: I4ecd2a191a7fd023aa82d80a3736b56de39b41f3
2022-01-24 04:22:04 +00:00
"johnkary/phpunit-speedtrap": "^4.0",
build: Update mediawiki-codesniffer from v37.0.0 to v38.0.0 Change-Id: Iff096d3789b8c261aa47fb41d6f450a3bda7ce6a
2021-10-22 20:43:16 +00:00
"mediawiki/mediawiki-codesniffer": "38.0.0",
phan: Upgrade mediawiki-phan-config to 0.11.1 and set minimum_target_php_version MediaWiki still supports PHP 7.2+, but we want to mainly test in newer versions of PHP. Setting minimum_target_php_version to 7.2 this lets us run phan without phan trying to get us to make PHP 7.2-incompatible changes to 'appease' PHP 8.0 or whatever later changes. Some switches of generic 'resource' type-hinting to 'resource|object' to inform phan to ignore this (triggering PHPCS at the time, ah well), rather than trying to hint the specific novel PHP encapsulation classes to that have replaced them from PHP 8.0 onwards but don't yet exist, and fixes from where we were checking the results of implode and explode. Bug: T293924 Change-Id: I629e3fb3adfad73beb3d424a07e643c2e079d9bb
2021-12-20 12:24:56 +00:00
"mediawiki/mediawiki-phan-config": "0.11.1",
composer.json: Relax some constraints for some dev requirements Change-Id: Ife7ddb98e3c1064a4e4e70f119549b2a1394e2d7
2021-10-08 19:21:38 +00:00
"nikic/php-parser": "^4.10.2",
composer: Upgrade php-parallel-lint to 1.2.0 and php-console-highlighter to 0.5 Depends-On: I3003ab0586d129d84a01c9b2e99f07e7dcf19367 Change-Id: I4d23087ea24a80fcefda965b3b47696012ef5bd6
2020-06-04 21:51:37 +00:00
"php-parallel-lint/php-console-highlighter": "0.5",
build: Updating dependencies composer: * php-parallel-lint/php-parallel-lint: 1.3.0 → 1.3.1 npm: * @wdio/mocha-framework: 7.4.6 → 7.13.2 * https://npmjs.com/advisories/5197 (CVE-2021-3807) * nth-check: 2.0.0 → 2.0.1 * https://npmjs.com/advisories/5101 (CVE-2021-3803) * ansi-regex: 5.0.0 → 5.0.1 * https://npmjs.com/advisories/5197 (CVE-2021-3807) Change-Id: I0b17591a4d230192d5c64b68252bb3024ddcedae
2021-10-04 06:38:16 +00:00
"php-parallel-lint/php-parallel-lint": "1.3.1",
Upgrade to PHPUnit 8 Bug: T192167 Depends-On: I1bdf465ab6d5e400f64e5325bc03bd6d62f319c7 Change-Id: Ia12658554c94497a204b7f65f1a6f7b1fa0310ac
2019-11-21 17:49:05 +00:00
"phpunit/phpunit": "^8.5",
Upgrading psy/psysh (v0.10.12 => v0.11.1) Change-Id: Ie4febaf054f86bf44cef0e1b2cd4f0500183b77d Depends-On: I991511ca3384513aa5c300b89e9dac7cb10104e5
2022-01-29 23:26:34 +00:00
"psy/psysh": "^0.11.1",
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",
Add partial support for running Parsoid selser tests * This patch only adds support for - selser manual edits tests - selser changetree [5] tests Both these types of selser tests are known statically. * This doesn't yet add support for selser auto-edit tests since they cannot be determined statically. There is some code already in place in the test runner to apply change trees, but it will all likely get refactored in a future patch. Bug: T270311 Depends-On: I3be7826e08be120043f3bcd9151bade930b65fb7 Change-Id: Ic824dae6ee49867c766d40c11acfda117c7e2689
2022-04-04 10:44:11 +00:00
"wikimedia/alea": "^0.9.3",
Updating wikimedia/testing-access-wrapper (1.0.0 => 2.0.0) Bug: T268846 Change-Id: I4f550864687241098b86eb9c5de6895424165985 Depends-On: Ieef3d5af038bc0b0fabe7af94e3f4b1d7afa0b51
2020-11-27 03:06:38 +00:00
"wikimedia/testing-access-wrapper": "~2.0",
Bump hamcrest-html-matchers to 1.0.0 Change-Id: I260f060e70ca5e3658c629c341faec38899a67cc
2021-04-20 12:41:37 +00:00
"wmde/hamcrest-html-matchers": "^1.0.0"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
build: Don't install symfony/polyfill-* that we require We require ext-ctype and ext-mbstring, so there's no need to install their polyfills. These are just development dependencies, but the less, the better. Change-Id: I437e5e96092de1d372a031f5b69ddefcd19b31d7
2019-01-21 22:22:31 +00:00
"replace": {
"symfony/polyfill-ctype": "1.99",
"symfony/polyfill-mbstring": "1.99"
},
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"suggest": {
composer.json: Document what the suggested php extensions enable Follows-up I795e785dd70f10. Bug: T302540 Change-Id: I3436bda1e3fa930b92addbb3412af5a7ac64f431
2022-03-06 00:45:43 +00:00
"ext-apcu": "Faster web responses overall.",
"ext-curl": "Faster HTTP services, e.g. when using InstantCommons, Swift, or Etcd.",
"ext-gd": "Enable thumbnails for file uploads.",
"ext-mysqli": "Enable the MySQL and MariaDB database type for MediaWiki.",
"ext-openssl": "Encrypt session data (or opt-out via $wgSessionInsecureSecrets).",
"ext-pdo": "Enable the SQLite database type for MediaWiki.",
"ext-pgsql": "Enable the PostgreSQL database type for MediaWiki.",
"ext-posix": "Enable CLI concurrent processing, e.g. for runJobs.php.",
"ext-pcntl": "Enable CLI concurrent processing, e.g. for runJobs.php and rebuildLocalisationCache.php.",
"ext-readline": "Enable CLI history and autocomplete, e.g. for eval.php and other REPLs.",
"ext-sockets": "Enable CLI concurrent processing, e.g. for rebuildLocalisationCache.php.",
"ext-wikidiff2": "Faster text difference engine.",
"ext-zlib": "Enable use of GZIP compression, e.g. for SqlBagOStuff (ParserCache), $wgCompressRevisions, or $wgUseFileCache.",
Remove deprecated EventRelayerKafka and KafkaHandler Also remove the unmaintained kafka-php package from the from "suggested" and "dev" composer dependencies, as this is now no longer used. Change-Id: If5668974f417b627df95bce47db18d46fa03327c
2022-03-25 00:06:08 +00:00
"monolog/monolog": "Enable use of MonologSpi ($wgMWLoggerDefaultSpi)."
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
},
"autoload": {
"psr-0": {
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",
Exclude node_modules from php lint script Some node modules include PHP scripts, and these files shouldn't be analyzed. This could be improved further by excluding `extensions/*/{node_modules,vendor}`, but I wasn't able to find a way to represent this for php-parallel-lint without listing each directory individually. For comparison, .phpcs.xml has this line to exclude dependencies: <exclude-pattern type="relative">^(\.git|coverage|node_modules|vendor)/*</exclude-pattern> Change-Id: I285eb32f67b71eaf111c9c9cd12f8205ba97eaf3
2022-01-24 22:38:59 +00:00
"lint": "parallel-lint --exclude node_modules --exclude vendor",
Fix 'composer phan' command Use --long-progress-bar, not -p, as the former is clearer, and also more suitable for CI logs. It's also what LibUp would add. Follow-Up: I119224c37a10d2a59068f899baffc6406ea60335 Bug: T253477 Change-Id: Ibd94fb14561e5abef55fdc0a288ace5d50447221
2020-12-23 16:44:17 +00:00
"phan": "phan -d . --long-progress-bar",
phpcs: Use cache flag This will use a temporary cache directory for the files analyzed by phpcs, so that subsequent runs are fast. Bug: T209149 Change-Id: I15967d220c1dbf9f06551cf4a5d01af5ddb739b6
2021-07-06 11:26:55 +00:00
"phpcs": "phpcs -p -s --cache",
build: Updating npm dependencies * ini: 1.3.5 → 1.3.8 * https://npmjs.com/advisories/1589 Additional changes: * Removed useless -p option to phpcbf in "composer fix" command. * Set `root: true` in .eslintrc.json (T206485). Change-Id: I0116578751fd73e43b07c2830adc629f4b85c784
2021-01-03 22:29:28 +00:00
"fix": [
"phpcbf"
],
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",
Revert "phpunit: Default to vendor/bin/phpunit, remove suites.xml" This caused unexpected problems with no obvious fixes. Needs more work. This reverts commit 7238dff532d035644b1f3adc41816e8523b35f23. Bug: T310255 Bug: T90875 Change-Id: I3758cbb6d0029b20ec1b0f67dbf2f422031c50ae
2022-06-09 14:15:54 +00:00
"releasenotes": "@phpunit:entrypoint --group ReleaseNotes",
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"test": [
composer.json: Swap `composer foo` for `@foo` Change-Id: Ib65ad97e49ba1b847c19ce1805f32b42382882cd
2021-11-24 16:40:04 +00:00
"@lint .",
"@phpcs ."
Define unit and integration test suites Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch proposes to further reduce the scope of what unit tests may access, by removing the loading of DefaultSettings and GlobalFunctions.php. This also has the implied effect of disabling the storage backend, as well as the global service locator. MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and purpose is more clear. Whether we still need to keep `@group Database` annotation around is debatable, as it's unclear to me what the performance costs are of implying database access for all tests which extend IntegrationTestCase. As far as I can tell, `@group Database` is primarily used in CI to run faster tests before slower ones, and with the new UnitTestCase the annotation seems redundant. To run all testsuites, use `composer phpunit`. Other composer scripts: - `composer phpunit:unit` to run unit tests - `composer phpunit:integration` to run integration tests - `composer phpunit:coverage` to generate code coverage reports from unit tests (requires XDebug). Note that you can pass arguments to composer scripts with `--`, e.g. `composer phpunit:integration --exclude-group Dump`. Other changes: - Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of the legacy PHPUnit-as-maintenance-class setup - Create new bootstrap.php which loads the minimal configuration necessary for the tests, and do additional setup in the run() method of the unit/integration test case classes - Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being the default test configuration For a follow-up patch: - Find unit/integration tests for extensions/skins - Migrate other test suites from suite.xml - Support running all tests via vendor/bin/phpunit Bug: T84948 Bug: T89432 Bug: T87781 Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
2019-06-26 02:33:14 +00:00
],
composer: Provide `test-some` job for CI Bug: T199403 Change-Id: I901d8d6bfbaeab2fcc3abf528804724f2841f5ec
2021-02-13 02:22:47 +00:00
"test-some": [
composer.json: Swap `composer foo` for `@foo` Change-Id: Ib65ad97e49ba1b847c19ce1805f32b42382882cd
2021-11-24 16:40:04 +00:00
"@lint",
"@phpcs"
composer: Provide `test-some` job for CI Bug: T199403 Change-Id: I901d8d6bfbaeab2fcc3abf528804724f2841f5ec
2021-02-13 02:22:47 +00:00
],
Revert "phpunit: Default to vendor/bin/phpunit, remove suites.xml" This caused unexpected problems with no obvious fixes. Needs more work. This reverts commit 7238dff532d035644b1f3adc41816e8523b35f23. Bug: T310255 Bug: T90875 Change-Id: I3758cbb6d0029b20ec1b0f67dbf2f422031c50ae
2022-06-09 14:15:54 +00:00
"phpunit": "php tests/phpunit/phpunit.php",
"phpunit:unit": "phpunit --colors=always --testsuite=core:unit,extensions:unit,skins:unit",
composer.json: Reference a single phpunit script Make use of `@` reference so that phpunit is invoked from a centrally defined command. Otherwise phpunit:integration defaults to `vendor/bin/phpunit` when `tests/phpunit/phpunit.php` may be desired instead. `composer phpunit:unit` does not use the composer.json defined phpunit command, as it must use `vendor/bin/phpunit` and not `tests/phpunit/phpunit.php`; the latter expects a LocalSettings.php file which is not in place at the time that `composer phpunit:unit` runs in CI. See https://getcomposer.org/doc/articles/scripts.md#referencing-scripts Change-Id: I13f947637060698226b6e5a2b593655798196de0
2022-06-07 10:53:59 +00:00
"phpunit:integration": "@phpunit --colors=always --testsuite=core:integration,extensions:integration,skins:integration",
"phpunit:coverage": "@phpunit --testsuite=core:unit --exclude-group Dump,Broken",
Add a composer command for the custom PHPUnit entry point This is meant to ease migration from the custom entry point to the standard vendor/bin/phpunit in a fashion that is essentially invisible to any consumer of this command. So after this change is merged we can change everything that uses tests/phpunit/phpunit.php to use this composer shortcut, and then eventually make the shortcut point to vendor/bin/phpunit with the right configuration. Bug: T90875 Change-Id: I2388610cda4fcbe87a4187c04ff624db5fa4d17c
2021-05-22 13:27:12 +00:00
"phpunit:coverage-edit": "ComposerPhpunitXmlCoverageEdit::onEvent",
Revert "phpunit: Default to vendor/bin/phpunit, remove suites.xml" This caused unexpected problems with no obvious fixes. Needs more work. This reverts commit 7238dff532d035644b1f3adc41816e8523b35f23. Bug: T310255 Bug: T90875 Change-Id: I3758cbb6d0029b20ec1b0f67dbf2f422031c50ae
2022-06-09 14:15:54 +00:00
"phpunit:entrypoint": "@phpunit -c tests/phpunit/suite.xml"
Set optimize-autoloader: true and prepend-autoloader: false in composer.json Quoting Tim from 240fd31cfa6b in mediawiki/vendor (prepend-autoloader): Composer's autoloader is slow, taking about 63µs per class, whereas MediaWiki's is fast, taking about 7µs per class. This adds up to an overhead of about 13% of CPU time on short requests such as API calls. On those same short requests, MediaWiki's autoloader finds most of the classes. So it makes sense to run it first, before the two Composer autoloaders. So change the config so that composer passes $prepend=false to spl_autoload_register(). optimize-autoloader is also just a good idea in general. Change-Id: I383c72a85eda415da92e8a9253e83b4ed591768b
2014-12-02 17:19:18 +00:00
},
"config": {
composer.json: alphabetize sections Alphabetize the entries in require, require-dev, suggest, scrips and config sections of the composer.json configuration file. Change-Id: Ibcfdc428045581674620e2a552b9b49ab1b24f3d
2015-09-27 05:16:10 +00:00
"optimize-autoloader": true,
composer.json: Add wikimedia/composer-merge-plugin to allow-plugins Bug: T298283 Change-Id: If1ca75740394b807467ba8b139d996adc38378c0
2021-12-23 23:11:52 +00:00
"prepend-autoloader": false,
"allow-plugins": {
composer.json: Temporarily allow composer/package-versions-deprecated plugin Should be removeable after release and integration of newer doctine/dbal release Bug: T298283 Change-Id: Ia91325bb9ac89cd1ff6831251ae291764892b143
2022-01-04 22:56:39 +00:00
"composer/package-versions-deprecated": true,
composer.json: Add wikimedia/composer-merge-plugin to allow-plugins Bug: T298283 Change-Id: If1ca75740394b807467ba8b139d996adc38378c0
2021-12-23 23:11:52 +00:00
"wikimedia/composer-merge-plugin": true
}
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