Dependency Management for PHP
https://getcomposer.org/
Composer is a dependency manager tracking local dependencies of your projects and libraries.
- Devel package for openSUSE:Factory
-
2
derived packages
- Links to openSUSE:Factory / php-composer
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout server:php:applications/php-composer && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
LICENSE | 0000001068 1.04 KB | |
README.md | 0000002364 2.31 KB | |
_link | 0000000124 124 Bytes | |
composer.phar | 0001999995 1.91 MB | |
php-composer.changes | 0000043555 42.5 KB | |
php-composer.spec | 0000002302 2.25 KB |
Revision 71 (latest revision is 80)
- Add provides of php8-composer - Version 1.10.19 * Fixed regression on PHP 8.0 - Version 1.10.18 * Allow installation on PHP 8.0 - Version 1.10.17 * Fixed Bitbucket API authentication issue * Fixed parsing of Composer 2 lock files breaking in some rare conditions - Version 1.10.16 * Added warning to validate command for cases where packages provide/ replace a package that they also require * Fixed JSON schema validation issue with PHPStorm * Fixed symlink handling in archive command - Version 1.10.15 * Fixed path repo version guessing issue - Version 1.10.14 * Fixed version guesser to look at remote branches as well as local ones * Fixed path repositories version guessing to handle edge cases where version is different from the VCS-guessed version * Fixed COMPOSER env var causing issues when combined with the global command * Fixed a few issues dealing with PHP without openssl extension (not recommended at all but sometimes needed for testing)
Comments 2
I plan to remove php-composer from Factory/Tumbleweed and add some code to php-composer2 to replace the old php-composer package. Are there any concerns against that decision? My plan is to do that transition at the beginning of October as long as there are no concerns.
I think it is totally fine. I have been using composer2 for quite a long time.