Today I streamlined the dependencies in the TYPO3 Flow  base distribution as well as the contained packages to avoid potential surprises and speed up installation. And I have to admit that I am still learning and developing best practices when it comes to using composer besides simply requiring a package, eve though we replaced our own half-baked package/dependency management with composer quite some time ago.

Speeding up composer install

One of the complaints with composer from Flow users was that it is slow. When installing dependencies, cloning all the packages takes some time. And for every new install or update, that time is needed again. But, to be honest, that is not entirely composers fault. Because we were developing heavily, we resorted to this in our root manifest:

"minimum-stability": "dev"

This makes composer pull in the latest development version of dependencies, even if they have no versions tagged yet at all. Sounded fine to us and did the job. Now, looking more closely, it becomes obvious that we do not need to pull in the latest development version of all our requirements–just of our own packages.

Removing the minimum stability setting broke the install, though, because the set of requirements could not be resolved due to not all packages being available in a stable version. And since stability flags are only observed in the root manifest, requiring dev-master of a package does not allow for dev dependencies of that package in turn.

In the end the solution is quite simple, once you dig through composer's behavior. The following example requires dev-master of typo3/flow and specifies a stability flag only for typo3/fluid and typo3/party–the require directive for them actually coming from the typo3/flow package. Et voilà: dev-master can be installed even though we do not set a minimum stability.

"require": {
  "typo3/flow": "dev-master",
  "typo3/fluid": "@dev",
  "typo3/party": "@dev"
}

In the end this allows us to use any package in dev or beta state as needed–but if we do not specify anything explicitly, the latest suitable stable version will be used. This gives us more security against unwanted changes being pulled in, but most of all it speeds up installation tremendously because composer can fetch archives for tagged versions instead of having to clone git repositories.

Update: I recorded a small screencast showing the speed gain achieved with this simple measure.

Testing dependency changes

Testing changes to composer requirements can seem impossible. If you change the composer manifest of a dependency you pull in, those changes will not be picked up and observed until you push those changes to the repository composer fetches the dependency from. Only changes to the root manifest can be tested without committing or pushing things anywhere.

If you are like me, you do not like a polluted history in your git repositories, so a workaround is needed. There is an easy one, though. Simply push forks of the packages you work on somewhere and tell composer to use those forks before any other source by simply adding a repositories section to your root manifest:

"repositories": [
  {
    "type": "git",
    "url": "https://github.com/kdambekalns/flow"
  }
]

Now push changes there until everything works. Afterwards clean up as needed and push the final changes to the official repository. If you do not want to fork, feel free to use a branch instead by using an inline alias in your root manifest. This example assumes you push your changes to the trial-and-error branch of the repositories used by default:

"require": {
  "typo3/flow": "dev-trial-and-error as dev-master"
}