UPGRADE-2.0.md
composer check-platform-reqs with the production PHP process as part of your build or deployment process.~/.composer if both are available (1.x used ~/.composer first)update now lists changes to the lock file first (update step), and then the changes applied when installing the lock file to the vendor dir (install step)HTTPS_PROXY_REQUEST_FULLURI if not specified will now default to false as this seems to work better in most environmentsdev-trunk, dev-master and dev-default are no longer aliases for each other. The exact branch names are now preserved.PluginInterface::PLUGIN_API_VERSIONPluginInterface added a deactivate (so plugin can stop whatever it is doing) and an uninstall (so the plugin can remove any files it created or do general cleanup) method.EventSubscriberInterface will be deregistered from the EventDispatcher automatically when being deactivated, nothing to do there.Pool objects are now created via the RepositorySet class, you should use that in case you were using the Pool class directly.Composer\Installer class changed quite a bit internally, but the inputs are almost the same:
setAdditionalInstalledRepository is now setAdditionalFixedRepositorysetUpdateWhitelist is now setUpdateAllowListsetWhitelistDependencies, setWhitelistTransitiveDependencies and setWhitelistAllDependencies are now all rolled into setUpdateAllowTransitiveDependencies which takes one of the Request::UPDATE_* constantssetSkipSuggest is gonevendor/composer/installed.json format changed:
"packages" top level key instead of the whole file being the package array"installed-path" key which lists where they were installed"dev" key which stores whether dev requirements were installed or notOperationInterface::getReason as the data was not accurate. There is no replacement available.PreFileDownloadEvent now receives an HttpDownloader instance instead of RemoteFilesystem, and that instance cannot be overridden by listeners anymore, you can however call setProcessedUrl or setCustomCacheKey.VersionSelector::findBestCandidate's third argument (phpVersion) was removed in favor of passing in a complete PlatformRepository instance into the constructorInitCommand::determineRequirements's fourth argument (phpVersion) should now receive a complete PlatformRepository instance or null if platform requirements are to be ignoredIOInterface now extends PSR-3's LoggerInterface, and has new writeRaw + writeErrorRaw methodsRepositoryInterface changes:
loadPackages(array $packageNameMap, array $acceptableStabilities, array $stabilityFlags) function was added for use during pool buildingsearch now has a third $type argumentgetRepoName() function was added to describe the repositorygetProviders() function was added to list packages providing a given package's nameBaseRepository abstract classDownloaderInterface changes:
download now receives a third $prevPackage argument for updatesdownload should now only do network operations to prepare the package for installation but not actually install anythingprepare (do user prompts or any checks which need to happen to make sure that install/update/remove will most likely succeed), install (should do the non-network part that download used to do) and cleanup (cleaning up anything that may be left over) were added as new steps in the package install flowRemoteFilesystem you probably should use HttpDownloader instead nowPRE_DEPENDENCIES_SOLVING and POST_DEPENDENCIES_SOLVING events have been removed, use the new PRE_OPERATIONS_EXEC, PRE_POOL_CREATE or other existing events instead or talk to us if you think you really need this. See below for more details.The update and install process have been split up.
Update does:
Install then does:
Composer 2.0 adds support for a new Composer repository format.
It is possible to build a repository which is compatible with both Composer v1 and v2, you keep everything you had and simply add the new fields in packages.json.
Here are examples of the new values from packagist.org:
"metadata-url": "/p2/%package%.json",
This new metadata-url should serve all packages which are in the repository.
%package% by the package name, and fetch that URL.$packageName~dev (e.g. /p2/foo/bar~dev.json to look for foo/bar's dev versions).foo/bar.json and foo/bar~dev.json files containing package versions MUST contain only versions for the foo/bar package, as {"packages":{"foo/bar":[ ... versions here ... ]}}.Composer\Util\MetadataMinifier::minify(). If you do that, you should add a "minified": "composer/2.0" key at the top level to indicate to Composer it must expand the version list back into the original data. See https://repo.packagist.org/p2/monolog/monolog.json for an example.If your repository only has a small number of packages, and you want to avoid the 404-requests, you can also specify an "available-packages" key in packages.json which should be an array with all the package names that your repository contain. Alternatively you can specify an "available-package-patterns" key which is an array of package name patterns (with * matching any string, e.g. vendor/* would make composer look up every matching package name in this repository).
"providers-api": "https://packagist.org/providers/%package%.json",
The providers-api is optional, but if you implement it, it should return packages which provide a given package name, but not the package which has that name. For example https://packagist.org/providers/monolog/monolog.json lists some package which have a "provide" rule for monolog/monolog, but it does not list monolog/monolog itself.
This is also optional, it should accept an optional ?filter=xx query param, which can contain * as wildcards matching any substring.
It must return an array of package names as {"packageNames": ["a/b", "c/d"]}. See https://packagist.org/packages/list.json?filter=composer/* for example.
It should return the names of package which names match the filter (or all names if no filter is present). Replace/provide rules should not be considered here.