public-mirrors
/
composer
mirror of https://github.com/composer/composer
1
0
Fork 0
Code

Merge branch 'master' of github.com:composer/composer into capath 

* 'master' of github.com:composer/composer:
  fix typo
  minor tweaking of phrasing
  move to troubleshooting
  add possible work-around / solution
  initial document
pull/4805/head
Rob Bast 2016-01-21 15:00:45 +01:00
parent 446f1b3e31 06a21132db
commit 1adb2e6005
1 changed files with 23 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/articles/troubleshooting.md
View File

@ -74,6 +74,29 @@ This is a list of common pitfalls on using Composer, and how to avoid them.
checking out. Using this, the checkout will not be in detached state any more and cyclic
dependency is recognized correctly.
## I have a dependency which contains a "repositories" definition in its composer.json, but it seems to be ignored.
The [`repositories`](04-schema.md#repositories) configuration property is defined as [root-only]
(04-schema.md#root-package). It is not inherited. You can read more about the reasons behind this in the "[why can't
composer load repositories recursively?](articles/why-can't-composer-load-repositories-recursively.md)" article.
The simplest work-around to this limitation, is moving or duplicating the `repositories` definition into your root
composer.json.
## I have locked a dependency to a specific commit but get unexpected results.
While Composer supports locking dependencies to a specific commit using the `#commit-ref` syntax, there are certain
caveats that one should take into account. The most important one is [documented](04-schema.md#package-links), but
frequently overlooked:
> **Note:** While this is convenient at times, it should not be how you use
> packages in the long term because it comes with a technical limitation. The
> composer.json metadata will still be read from the branch name you specify
> before the hash. Because of that in some cases it will not be a practical
> workaround, and you should always try to switch to tagged releases as soon
> as you can.
There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.
## Need to override a package version
Let's say your project depends on package A, which in turn depends on a specific