, (*1)
Manage repositories defined inside your composer.json, (*2)
Current functionality is limited to converting github repositories of type git to type vcs (which then enables composer to download archive dists instead of cloning every time)., (*3)
It is also heavily opinionated for the use case I had when writing it, so your mileage may vary and pull requests welcome., (*4)
Installation
If you're even thinking of using this tool, you're already familiar with composer. It's all pretty standard., (*5)
$ composer require --dev xiian/composer-repo-tool
This will install ./vendor/bin/composer-repo-tool for use inside your project., (*6)
You can also install globally:, (*7)
$ composer global require --dev xiian/composer-repo-tool
Which installs into $COMPOSER_HOME/vendor/bin/, which should already be in your $PATH., (*8)
Usage
To update a single package's repository:, (*9)
$ composer-repo-tool update $VENDOR/$PACKAGE
To update all repositories:, (*10)
$ composer-repo-tool update:all
You can also pass a --dry-run flag to see what the tool would do, without actually doing any of it., (*11)
Under the Hood
The update command will perform the following steps for each package given:, (*12)
- Rewrite the
composer.json repositories entry for the given package
- Use
vcs instead of git
- Convert URL from
git@$GITHUB_URL:$USER/$REPO.git to https://$GITHUB_URL/$USER/$REPO.git
- Phsycially remove the package from the
vendor/ directory
- Run
composer update with proper params to switch to using dist instead of source
- Perform a git commit of the
composer.lock and composer.json files. (I told you this was opinionated)
The update:all command will perform the above steps for every single package that is installed that does not have a dist associated with it in the composer.lock file., (*13)
TODO
-
Decouple the source control stuff. I like the idea of being able to perform a task after every package has been updated (for atomicity), but not everybody wants the same thing.
-
Batch mode.
update:all is kind of slow because it's performing the full update cycle for every package. If atomicity isn't a concern, all of those updates could be done together, and composer update would only need to be run once, which would greatly speed things up.
-
Integrate with
composer more directly. Using the internals of composer/composer could speed things up a bit by skipping some likely redundant steps of composer update.
Wallogit.com
