forcing composer to regenerate autoloads when composer.json of a dependency is changed?

Question

My workflow for developing Symfony bundles is the following:

• install Symfony
• create a git repo for the new bundle, put a composer.json file in there
• require the new package in the top-level composer.json, using @dev version
• composer update newpackage => the package is downloaded, using git clone
• work on the git clone inside vendors, committing and pushing from it

This is all fine and dandy, but seems to break in one specific case: if I alter the 'autoload' tag of the already-installed package, it seems that Composer has a hard time taking it into account:

• I tried 'composer dumpautoload', and it does nothing
• I do not want to remove the composer.lock file, as I do not want other packages to be updated to a newer version, I only want to alter the autoload config of that one package
• I tried removing by hand vendor/composer/installed.json, and what happened is that Composer re-downloaded all the vendors and wiped any data which happened to be in there at that moment

The same problem manifested itself when I did alter the autoload section of the package on a separate clone, pushed the changes to git and ran 'composer update mypackage' - although that might have been related to packagist not having received the ping from github.

I can of course alter by hand the composer.lock and vendor/composer/installed.json files, but that seems too hackish. It also does not gives the guarantee that user downloading the package the 1st time will see it working.

Answer 1

Try:

./composer.phar dumpautoload -o

It reads the composer.json files and rewrites all the autoload files which pick up the new paths.

Answer 2

dumpautoload uses the package information from vendor/composer/installed.json and not the individual composer.json files. You need to change the autoload info there, too.

Answer 3

The file installed.json is only being update when you run a

composer update