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

131 lines
3.8 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/"
},
"require": {
Update some composer dependancies Update composer/semver from 1.4.2 to 1.5.0 https://github.com/composer/semver/releases/tag/1.5.0 https://github.com/composer/semver/compare/1.4.2...1.5.0 Update composer/spdx-licenses from 1.4.0 to 1.5.1 https://github.com/composer/spdx-licenses/compare/1.4.0...1.5.1 https://github.com/composer/spdx-licenses/releases/tag/1.5.1 Update mediawiki/codesniffer from 25.0.0 to 26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/releases/tag/v26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/compare/25.0.0...v26.0.0 Disable failing Squiz.WhiteSpace.FunctionSpacing, can be fixed in a later commit Change-Id: I89062c8f28bef893f054650f2e81287291ba9ca0 Depends-On: I8f55e77283f83d853ce340f5c1b7704c65e45bc4
2019-05-10 23:19:25 +00:00
"composer/semver": "1.5.0",
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": "*",
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": "*",
Create GuzzleHttpRequest class as new default for HttpRequestFactory Create a GuzzleHttpRequest class using the external Guzzle (docs.guzzlephp.org) library. This will be the new default request type, but CurlHttpRequest and PhpHttpRequest remain available and accessible via Http::$httpEngine. Bug: T202110 Change-Id: Ie720be2628d7baf427b002847f103fd86ee4cff3 Depends-On: I143a6410d111e75f01dbbfd43f300e2e60247451
2018-08-17 14:53:59 +00:00
"guzzlehttp/guzzle": "6.3.3",
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.31.6 Release notes: https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v0.31.6 Bug: T220792 Bug: T222088 Bug: T222427 Depends-On: Id1eae9aa3105886d557a6d11af68fff633602970 Change-Id: Ie40cf6c8eb8ad77f99512db56026827de4d636fa
2019-05-08 10:50:49 +00:00
"oojs/oojs-ui": "0.31.6",
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",
"pear/mail_mime": "1.10.2",
Updated pear/net_smtp from 1.8.0 to 1.8.1 Depends-On: I6543ac3e6482da197ce2d644823861d1db4624d8 Change-Id: I91b3c2864536a53fcc829a1e10a3bc0d4638db2b
2019-02-10 23:00:06 +00:00
"pear/net_smtp": "1.8.1",
Bump PHP version requirement to 7.0.0+ Bug: T172165 Change-Id: I740f32ac859d9bb3787fdf8414f82ae6f410492f
2018-01-18 23:34:32 +00:00
"php": ">=5.6.99",
Update psr/log to v1.0.2 https://github.com/php-fig/log/compare/1.0.0...1.0.2 https://github.com/php-fig/log/releases/tag/1.0.1 https://github.com/php-fig/log/releases/tag/1.0.2 Change-Id: I63bc43ec352d4fe756596cfcb46320e5e02edf7a Depends-On: I7d4e1d7f61c56fb8951744e0a149b4a3df480e5b
2017-02-09 16:15:13 +00:00
"psr/log": "1.0.2",
Start using the Assert helper class for checking parameters. This introduces https://github.com/wmde/Assert as a dependency, as discussed in the RFC T91071. This change uses assertions to check some parameters in some places, to showcase the main intended use case for assertions in MediaWiki. Bug: T91071 Change-Id: I93ac39b7c146f10532e37b51d973b59b9c424b2f
2015-04-22 16:46:29 +00:00
"wikimedia/assert": "0.2.2",
Swap mediawiki/at-ease for wikimedia/at-ease Bump wikimedia/php-session-serializer to v1.0.6 Change-Id: I9ed96a29d6db39206377b45e3d46cb2082587f75 Depends-On: I963a61135d66b8baa4638979fd21077d925276b9
2018-04-18 12:35:14 +00:00
"wikimedia/at-ease": "1.2.0",
Update wikimedia/base-convert to 2.0.0 The breaking change is dropping PHP 5 support. Bug: T194052 Depends-On: I4de5c0ab827c96e2cef4e0b2cd7d10a109393668 Change-Id: If39ea5274bfa3c9b0ce18f9a43a27445a90ea3fc
2018-10-22 18:17:40 +00:00
"wikimedia/base-convert": "2.0.0",
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",
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 from 1.0.1 to 1.0.2 https://github.com/wikimedia/html-formatter/releases/tag/1.0.2 https://github.com/wikimedia/html-formatter/compare/1.0.1...1.0.2 Bug: T193318 Change-Id: I5f7a3e2300f343f675124df399cfe12909f56e14 Depends-On: Ia69102af64a0102e05b96b10f63ffcf6cbf292fa
2018-04-28 11:49:36 +00:00
"wikimedia/html-formatter": "1.0.2",
Update wikimedia/ip-set 2.0.0 to 2.0.1 Change-Id: I154a677bac28a451be4f203ff05ea4620260b54e Depends-On: I1090817a5ff1e406cf51596a8b1558c7bd3ca7d7
2019-02-12 00:28:49 +00:00
"wikimedia/ip-set": "2.0.1",
Use our fork of less.php Supports PHP 7.3, among other things Bug: T206975 Depends-On: I06f1e43b0f12f9b56f9dff55a92b5ae4546acfcc Change-Id: I84c5ed8ac0ae1c382ba035b37dc88ccd69494ac3
2018-10-16 07:00:30 +00:00
"wikimedia/less.php": "1.8.0",
Use wikimedia/object-factory 1.0.0 Deprecate the unnamespaced version and move it to includes/compat. Bug: T147167 Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
2018-02-02 10:27:27 +00:00
"wikimedia/object-factory": "1.0.0",
Update wikimedia/password-blacklist to v0.1.4 Change-Id: I881fdd3fd028d23f882544228c5d5ec46e830378 Depends-On: Iee09b60913aed6207e256ed4bfc9f7ee380cc20a
2018-12-04 08:15:15 +00:00
"wikimedia/password-blacklist": "0.1.4",
Update wikimedia/php-session-serializer from v1.0.6 to v1.0.7 Change-Id: Id30bb862bec42e508b3551d39f5980d900ade206 Depends-On: Ia19d237198fd2a0a15db467ec9dd97e98a857e33
2019-02-12 00:40:12 +00:00
"wikimedia/php-session-serializer": "1.0.7",
Update purtle to 1.0.7 Companion vendor change is https://gerrit.wikimedia.org/r/c/420911/ Bug: T185589 Change-Id: Ic3b4e902c212adbd25f7364259e3767d4e1dfb7a
2018-03-21 18:39:55 +00:00
"wikimedia/purtle": "1.0.7",
Update wikimedia dependencies Updated: * wikimedia/ip-set 1.1.0 -> 1.2.0 * wikimedia/relpath 2.0.0 -> 2.1.1 * wikimedia/running-stat 1.1.0 -> 1.2.1 * wikimedia/wrappedstring 2.2.0 -> 2.3.0 https://github.com/wikimedia/IPSet/compare/1.1.0...1.2.0 https://github.com/wikimedia/relpath/compare/2.0.0...2.1.1 https://github.com/wikimedia/runningstat/compare/v1.1.0...v1.2.1 https://github.com/wikimedia/WrappedString/compare/v2.2.0...v2.3.0 Bug: T182273 Change-Id: I23a734e7a5b9a7ff4d46901a9c5b3b51402687d5 Depends-On: Ib2402f41262549207c8386d74855240ca0d4a54b
2018-01-18 21:15:07 +00:00
"wikimedia/relpath": "2.1.1",
Upgrade wikimedia/remex-html to 2.0.1 Bug: T207088 Depends-On: Id4bbbdb68678c37ec4aa84d519516199bb800393 Change-Id: Ia5822f5f283f5d935c78402ce71e2d010e9a7a91
2018-10-21 05:12:14 +00:00
"wikimedia/remex-html": "2.0.1",
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",
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 wikimedia/timestamp to v2.2.0 Depends-On: Ibe47c7e363d263be37c7ebe3891e46f04a3481bd Change-Id: Id8901d0a0d30bf402220aca73f9c5f45043908ce
2018-09-24 04:32:19 +00:00
"wikimedia/timestamp": "2.2.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 3.0.1 Bug: T196496 Depends-On: I13dbdba2b9df52f2d4214c1327e20292c6941331 Change-Id: I5a5d7de4702c23f069c27bcf31b9ace97d54fd82
2018-06-05 21:56:11 +00:00
"wikimedia/wrappedstring": "3.0.1",
Update wikimedia/xmp-reader from 0.6.1 to 0.6.2 Change-Id: Ie396666aae2122dc552f6f1a7f6fe6ff96387fd1 Depends-On: Ia5dcf97548ed1c1f17cce9701df5cf13eea814dd
2019-02-12 01:24:17 +00:00
"wikimedia/xmp-reader": "0.6.2",
Update zordius/lightncandy to v0.23 Depends-On: If8cf6905c5b590ae3bb0297153e966d24ea3bcb8 Change-Id: I1aa2cb76680f4b0c60f3196cc92f0bd18cbcfd33
2015-12-19 00:28:26 +00:00
"zordius/lightncandy": "0.23"
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": {
Install cache/integration-tests as require-dev Bug: T199440 Change-Id: I1e50d7202a5d02088319ec9e90e0136519cba1ce
2018-07-18 10:47:27 +00:00
"cache/integration-tests": "0.16.0",
Update some composer dependancies Update composer/semver from 1.4.2 to 1.5.0 https://github.com/composer/semver/releases/tag/1.5.0 https://github.com/composer/semver/compare/1.4.2...1.5.0 Update composer/spdx-licenses from 1.4.0 to 1.5.1 https://github.com/composer/spdx-licenses/compare/1.4.0...1.5.1 https://github.com/composer/spdx-licenses/releases/tag/1.5.1 Update mediawiki/codesniffer from 25.0.0 to 26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/releases/tag/v26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/compare/25.0.0...v26.0.0 Disable failing Squiz.WhiteSpace.FunctionSpacing, can be fixed in a later commit Change-Id: I89062c8f28bef893f054650f2e81287291ba9ca0 Depends-On: I8f55e77283f83d853ce340f5c1b7704c65e45bc4
2019-05-10 23:19:25 +00:00
"composer/spdx-licenses": "1.5.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",
Add jakub-onderka/php-console-highlighter 0.3.2 explicitly We pin it in various libraries, might aswell in core for completenes Change-Id: I659c880c9e16e4eab7050874f75c9eb5c9fa958c
2019-02-11 03:27:55 +00:00
"jakub-onderka/php-console-highlighter": "0.3.2",
Update jakub-onderka/php-parallel-lint to 0.9.2 https://github.com/JakubOnderka/PHP-Parallel-Lint/releases Change-Id: I70bb67bb23e1607d1b005971d0cee3851f573d7a
2016-01-02 12:16:21 +00:00
"jakub-onderka/php-parallel-lint": "0.9.2",
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",
Update some composer dependancies Update composer/semver from 1.4.2 to 1.5.0 https://github.com/composer/semver/releases/tag/1.5.0 https://github.com/composer/semver/compare/1.4.2...1.5.0 Update composer/spdx-licenses from 1.4.0 to 1.5.1 https://github.com/composer/spdx-licenses/compare/1.4.0...1.5.1 https://github.com/composer/spdx-licenses/releases/tag/1.5.1 Update mediawiki/codesniffer from 25.0.0 to 26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/releases/tag/v26.0.0 https://github.com/wikimedia/mediawiki-tools-codesniffer/compare/25.0.0...v26.0.0 Disable failing Squiz.WhiteSpace.FunctionSpacing, can be fixed in a later commit Change-Id: I89062c8f28bef893f054650f2e81287291ba9ca0 Depends-On: I8f55e77283f83d853ce340f5c1b7704c65e45bc4
2019-05-10 23:19:25 +00:00
"mediawiki/mediawiki-codesniffer": "26.0.0",
Update monolog from 1.18.2 to 1.22.1 https://github.com/Seldaek/monolog/releases/tag/1.19.0 https://github.com/Seldaek/monolog/releases/tag/1.20.0 https://github.com/Seldaek/monolog/releases/tag/1.21.0 https://github.com/Seldaek/monolog/releases/tag/1.22.0 https://github.com/Seldaek/monolog/releases/tag/1.22.1 https://github.com/Seldaek/monolog/compare/1.18.2...1.22.1 Bug: T158707 Change-Id: Icfb87911486aee8b712ce643f0041f91eb6cc078 Depends-On: Id5a96aaba77e52290a5afaff2c01b29c285e67af
2017-02-21 21:44:18 +00:00
"monolog/monolog": "~1.22.1",
Update dev dependancies * Updated psy/psysh from 0.9.6 to 0.9.9 (dev-only). * Updated nikic/php-parser from 3.1.3 to 3.1.5 (dev-only). Change-Id: I05e45327e93d3bc733db73c0efe573b3223cc902 Depends-On: I896ac6c5afa8221ceca726eb7895e05d87d7e6f3
2019-02-10 22:37:29 +00:00
"nikic/php-parser": "3.1.5",
registration: Validate no duplicate keys exist in extension.json The JSON specification permits duplicate keys, but doing so is almost always nearly a mistake. We can use the JSON lint library (added as dev-requirement to composer), which is now also used to decode the JSON (as it's the same step as validating the JSON). Bug: T153507 Change-Id: Ia713a1906169333c1aa2aebdc0ed060d26428d72
2017-01-22 15:36:22 +00:00
"seld/jsonlint": "1.7.1",
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",
Allow PHPUnit 6 optionally in require-dev MediaWiki uses a back-compat layer to preserve most of the PHPUnit 4 runtime, so existing tests will continue to run fine with minimal modification. Once PHP < 7.0 support is dropped, we can drop PHPUnit 4 support, and adapt tests to use PHPUnit 6 features directly. Bug: T177132 Depends-On: I884b240307e3fcad253aa64eeae9944ed4eb7d50 Change-Id: I497712c7693d137be197a69873baa58383ce9646
2017-12-03 14:49:31 +00:00
"phpunit/phpunit": "4.8.36 || ^6.5",
Update dev dependancies * Updated psy/psysh from 0.9.6 to 0.9.9 (dev-only). * Updated nikic/php-parser from 3.1.3 to 3.1.5 (dev-only). Change-Id: I05e45327e93d3bc733db73c0efe573b3223cc902 Depends-On: I896ac6c5afa8221ceca726eb7895e05d87d7e6f3
2019-02-10 22:37:29 +00:00
"psy/psysh": "0.9.9",
Bump avro to 1.8 Adss PHP7 support. Bug: T177273 Change-Id: I38cf66d6602170cec3a307bfe44656db103c321f
2018-03-29 00:58:33 +00:00
"wikimedia/avro": "1.8.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",
Use mediawiki/mediawiki-phan-config 0.3.0 Use the library instead of duplicating most of the config/defaults that it provides. MediaWiki core is different of course, so we have to override a bunch of file/directory lists, but there was a lot being duplicated. This is the first step in migrating to a newer phan version. Change-Id: Ib5987ebdf208138d97e1aba8ef54438064063fe9
2019-03-21 22:28:48 +00:00
"wmde/hamcrest-html-matchers": "^0.1.0",
build: Upgrade mediawiki/mediawiki-phan-config from 0.5.0 to 0.6.0 and make pass Fix five instances of PhanPluginDuplicateConditionalNullCoalescing; escape the rest for now. Bug: T219114 Change-Id: Ic4bb30c43c5315ce6b878b37b432c6e219414f8b
2019-05-13 11:09:41 +00:00
"mediawiki/mediawiki-phan-config": "0.6.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",
"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",
"ComposerVendorHtaccessCreator": "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",
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
"fix": "phpcbf",
composer.json: alphabetize sections Alphabetize the entries in require, require-dev, suggest, scrips and config sections of the composer.json configuration file. Change-Id: Ibcfdc428045581674620e2a552b9b49ab1b24f3d
2015-09-27 05:16:10 +00:00
"pre-install-cmd": "ComposerHookHandler::onPreInstall",
"pre-update-cmd": "ComposerHookHandler::onPreUpdate",
SECURITY: Create a .htaccess in /vendor after composer runs The /vendor directory does not need to be web accessible, and to reduce attack surface, it should not be web accessible. We can use the post-install-cmd and post-update-cmd hooks to create a .htaccess after the user has run "composer install" or "composer update". On the first run of composer, this hook will be invoked twice due to the composer merge plugin. If the htaccess file already exists, this hook won't do anything. Bug: T180237 Change-Id: I2cf6541750c90b5708d7cf5f81b914ae2d9d46d1
2017-11-11 00:05:13 +00:00
"post-install-cmd": "ComposerVendorHtaccessCreator::onEvent",
"post-update-cmd": "ComposerVendorHtaccessCreator::onEvent",
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"test": [
"composer lint",
Revert "build: Run minus-x to check for executable files that shouldn't be" This reverts commit bd2a718cf09cc5826d5a1ef27b1fbb21741e4342. Bug: T212766 Change-Id: Ic453d7e672ad6c1e39f33f7efd104483f95f5b89
2019-01-02 10:19:43 +00:00
"composer phpcs"
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
]
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