That package in fact is available through packagist. You don’t need a custom repository definition in this case. Just make sure you add a require
(which is always needed) with a matching version constraint.
In general, if a package is available on packagist, do not add a VCS repo. It will just slow things down.
For packages that are not available via packagist, use a VCS (or git) repository, as shown in your question. When you do, make sure that:
- The “repositories” field is specified in the root composer.json (it’s a root-only field, repository definitions from required packages are ignored)
- The repositories definition points to a valid VCS repo
- If the type is “git” instead of “vcs” (as in your question), make sure it is in fact a git repo
- You have a
require
for the package in question - The constraint in the
require
matches the versions provided by the VCS repo. You can usecomposer show <packagename>
to find the available versions. In this case~2.3
would be a good option. - The name in the
require
matches the name in the remotecomposer.json
. In this case, it isgedmo/doctrine-extensions
.
Here is a sample composer.json
that installs the same package via a VCS repo:
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
The VCS repo docs explain all of this quite well.
If there is a git (or other VCS) repository with a composer.json
available, do not use a “package” repo. Package repos require you to provide all of the metadata in the definition and will completely ignore any composer.json
present in the provided dist and source. They also have additional limitations, such as not allowing for proper updates in most cases.
Avoid package repos (see also the docs).