Composer local Development Plugin
A composer plugin that assists you with local dependencies., (*1)
Imagine the following: You are developing two packages, A and B. Package A depends on B. In your normal workflow you would push changes you did in package B to github. .... Then wait.... until changes are pushed to packagist and caches are refreshed. Now you can run composer update in package A to get all the changes you did in package B. That's very ineffective, not only do you need to to push changes most importantly you need to wait for a change that is just a directory away. Here is a solution., (*2)
Installation
At best this plugin is installed globally, so go ahead:, (*3)
$ composer global require 'gossi/composer-localdev-plugin=dev-master'
$ composer global update
Usage
The priority in this plugin lies in the truth that you shouldn't change your packages code, it should just work as expected when pushed to github and others want to consume it. You only describe your local development to composer and the rest is handled by this plugin. Open '~/.composer/config.json' and add the localdev property to the root node:, (*4)
{
"config": {
"localdev": {
"": ["/path/to/your/packages"],
"sümfony": "/path/to/sümfony",
"my/package": "/path/to/my/package"
}
}
}
As you can see, you can define three types of folder types:, (*5)
- Global path: The plugin will look for vendor/package packages in these directories. E.g. if you are looking for
my/pkg it will look for it in /path/to/your/packages/my/pkg/.
- Vendor path: You can give a path for all packages of a certain vendor. E.g. if you are looking for
sümfony/finda it will look for it in /path/to/sümfony/finda/.
- Package path: Of course explicitly say where a specific package is located. E.g. the lookup for
my/package will find it at /path/to/my/package/.
For global and vendor packages you can give multiple paths by defining them as an array (see the difference between global and vendors paths in the example above - both are accepted)., (*6)
Run update/install
The neat idea is, you don't need to change your workflow at all. If you now run composer install or composer update in one of your packages, those packages that are available locally (described in the global composer config.json) will be symlinked to their original location. You will see something like the notice., (*7)
=> Symlinked phootwork/lang from /path/to/phootwork/lang
Pitfalls
At the moment, every package that can be found locally is symlinked no matter what. There must be something to control this, because sometimes you just want your package from packagist in the desired version number. Make your suggestions under Issue #3., (*8)
Issues
There are still some issues, that haven't been solved:, (*9)
- Dealing with custom installers: You may have custom installers, that change the installation destination of your package. Normally, the localdev plugin will just wrap them and both work as expected, yet there is a catch. These custom installers (composer plugins as this one) will be installed during the first installation of that required package. They will be unnoticed to the localdev plugin in the first run, so only the custom installer will work. At the moment, you need to run
composer update one more time to make them both work (See #1).
- "Ignore Discard Changes": I run across this issue, yet I don't remember what caused this one. I just keep it here as an reminder, there is something. If you run across this, please open an issue.
References
Contribute
Contributions are welcome, at best open an issue or add a comment to and existing one get the discussion going., (*10)
Wallogit.com
