Implement generate-classmap command #541

wants to merge 1 commit into


None yet

7 participants


Command to generate a class map. Should fix #127.
Will be used by autoload.php if present, with psr-0 as fall-back.

Composer member

This isn't exactly what I envisioned. The goal is to have the fastest autoloader we can provide for production use, so I would say it should perhaps override the autoload.php and autoload_classmap.php files - so that autoload only includes the classmap (no PSR-0 info), and the classmap contains everything, i.e. classmap + psr-0 packages.


Sorry I couldn't get back to this earlier.

ClassLoader will return the classmap entry if it exists before any other processing is done, as long as the generated classmap this PR generates exists, using normal PSR-0 processing for classes not in the classmap.
Perhaps I misunderstand, but do you mean to not use ClassLoader at all in the optimal/production case?

Composer member

Well this just builds an additional map for the PSR0 ones, so you have two maps, and the autoload.php file is still including various files + loading it all in the classloader. In theory if all the info is there, you don't even need to give the PSR0 info to the classloader, just loading it with the classmap should be enough.


Is there any reason why the method of generation should not be determined by the use, or lack of, --dev, instead of an additional command?


@dboune --dev is about installing additional dependencies needed to run the testsuite (or other dev tasks). I don't think it should control the optimization of the autoloader as they are unrelated topics


Yeah I thought about that too... But instead of dev option I would add the new one e.g. generate-classmap. The other solution would be a new command generate-autoloading which would generate any type of autoloading: default (for development: psr0+classmap+include_path), classmap, apc etc. This command would be called as a subcommand in the install and update command as well as separate one if it would be necessary (in production).


I was considering Saldaek's comment above about overriding (overwriting?) the autoload_classmap and autoload. There are somewhat unused tests already in AutoloadGenerator->getAutoloadFile that could generate an "optimized" autoload.php.

When requested, the code to generate the autoload_classmap could generate the additional entries needed to cover psr0, targetDir, (includePath?) as a single classmap.

Some switch would be needed to change the method used by AutoloadGenerator. Whatever that is could be used then by a command when calling AutoloadGenerator->dump().

@krymen That sounds nice. So the switch being an autoloader_type

For use, something like the following? (default being explicit in the example but otherwise normally implicit)

(Re)generate autoloader
composer.phar generate-autoloader default
composer.phar generate-autoloader classmap

Install with specific autoloader type
composer.phar install --autoloader=default
composer.phar install --autoloader=classmap

Edit: correcting my use of Command Options.


@dboune Exactly that was my thought. Imho API looks clear, is BC and extensible.

@Seldaek What do you think?


Another thought, adding to all the previous, is having a base AutoloadGenerator class, which could be extended for the various types.


Just to keep things nice and clean.. not sure if that would be going too far.


If so -- there should be AutoloadGeneratorInterface but I haven't looked in the implementation of AutoloaderGenerator that far. Nevertheless, the main matter now is to clarify the api of the command.


As stof mentions in #127 symfony's ApcClassLoader and XcacheLoader wrap another autoloader, so it is a separate concept from the generation of the data used by the autoloader.

Regardless of what type of data is provided to the ClassLoader an ApcClassLoader, or similar, could still be used.

That could create, conceptually, something like generate-autoloader --method={default,apc,xcache} --strategy={default,classmap}. I realize this PR is only concerned with what I just called the strategy (maybe I have the nomenclature wrong), but I thought it worthy to mention in relation to clarifying the api of the command since both parts are handled in AutoloadGenerator.

Also of note, Installer::__construct(..., autoloadGenerator $autoloadGenerator)


Has there been any recent progress with this?


Nope. Unfortunately I've had no time recently for doing this. Waiting for @Seldaek opinion on that as well.


any way I can help reignite this?

Composer member

See #811 for my take on this. Feedback welcome.

@Seldaek Seldaek closed this in 48c46ce Aug 14, 2012
@digitalkaoz digitalkaoz pushed a commit to digitalkaoz/composer that referenced this pull request Nov 22, 2013
@Seldaek Seldaek Automatically generate classmaps for all PSR-0 packages to speed thin…
…gs up, fixes #541, fixes #127
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment