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

move to troubleshooting

pull/4713/head
Rob Bast 2016-01-11 10:23:14 +01:00
parent 04fb28a9cb
commit aca19deffa
2 changed files with 23 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/articles/pitfalls.md
View File

@ -1,28 +0,0 @@
<!--
tagline: Common mistakes and misconceptions
-->
# Pitfalls
## 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 to 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 therefor strongly recommended that you do not use it.

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 checking out. Using this, the checkout will not be in detached state any more and cyclic
dependency is recognized correctly. 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 to 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 therefor strongly recommended that you do not use it.
## Need to override a package version ## Need to override a package version
Let's say your project depends on package A, which in turn depends on a specific Let's say your project depends on package A, which in turn depends on a specific