From aca19deffa1b441952996b201cf055bb6b0d60d5 Mon Sep 17 00:00:00 2001 From: Rob Bast Date: Mon, 11 Jan 2016 10:23:14 +0100 Subject: [PATCH] move to troubleshooting --- doc/articles/pitfalls.md | 28 ---------------------------- doc/articles/troubleshooting.md | 23 +++++++++++++++++++++++ 2 files changed, 23 insertions(+), 28 deletions(-) delete mode 100644 doc/articles/pitfalls.md diff --git a/doc/articles/pitfalls.md b/doc/articles/pitfalls.md deleted file mode 100644 index b3bfde8f7..000000000 --- a/doc/articles/pitfalls.md +++ /dev/null @@ -1,28 +0,0 @@ - - -# 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. diff --git a/doc/articles/troubleshooting.md b/doc/articles/troubleshooting.md index c03395d61..ca62952b6 100644 --- a/doc/articles/troubleshooting.md +++ b/doc/articles/troubleshooting.md @@ -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 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 Let's say your project depends on package A, which in turn depends on a specific