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 use composer 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 remote composer.json. In this case, it is gedmo/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).

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 use composer 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 remote composer.json. In this case, it is gedmo/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).

Since composer looks for a version tag/release and the use case is often that of using a personal fork of an existing package make sure to add one, since forking doesn't copy tags and without one you won't be able to install it with an obscure composer error.

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.

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 use composer 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 remote composer.json. In this case, it is gedmo/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).