Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Currently, whenever we run composer update or composer dump-autoload, we get at least four meaningful pieces of diff caused by the recalculation of the AutoloaderInit suffix.
E.g. in #2175447-1: Update composer to latest version:
-return ComposerAutoloaderInit50432d86c534be2ddddf85d27e021721::getLoader();
+return ComposerAutoloaderInitf089bd3ae5f9f883a3ebe89eb643eced::getLoader();
[..]
-class ComposerAutoloaderInit50432d86c534be2ddddf85d27e021721
+class ComposerAutoloaderInitf089bd3ae5f9f883a3ebe89eb643eced
[..]
- spl_autoload_register(array('ComposerAutoloaderInit50432d86c534be2ddddf85d27e021721', 'loadClassLoader'), true, true);
+ spl_autoload_register(array('ComposerAutoloaderInitf089bd3ae5f9f883a3ebe89eb643eced', 'loadClassLoader'), true, true);
[..]
- spl_autoload_unregister(array('ComposerAutoloaderInit50432d86c534be2ddddf85d27e021721', 'loadClassLoader'));
+ spl_autoload_unregister(array('ComposerAutoloaderInitf089bd3ae5f9f883a3ebe89eb643eced', 'loadClassLoader'));
There is a way to avoid this noise:
http://getcomposer.org/doc/04-schema.md
Look for "autoloader-suffix".
We could set this to e.g. "Drupal8" and be done with it.
The purpose of the random-generated suffix is to avoid collisions with other instances of Composer used in the same process/request.
I think we can expect that only one of these instances will be from a Drupal 8 installation. And even if there were more than one instance from Drupal 8, our current solution won't help at all because each of those instances will have the same random-generated suffix.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | composer-2176265-7.patch | 1.74 KB | tim.plunkett |
Comments
Comment #1
donquixote CreditAttribution: donquixote commentedComment #3
donquixote CreditAttribution: donquixote commented1: D8-composer-autoloader-suffix-2176265-1.patch queued for re-testing.
Comment #4
larowlanAwesome
Comment #5
tim.plunkettYeah, that suffix really worried me when I was working on the other patch, this is great.
Comment #6
dawehnerNice!
Comment #7
webchickThis patch is awesome.
However, it no longer applies. :(
Comment #8
tim.plunkettRerolled after #2173653: Update easyrdf/easyrdf to 0.8.0
Comment #9
donquixote CreditAttribution: donquixote commentedPatch from #8 still applies, Drupal install works fine for me, and "composer install" gives me an empty changeset.
Seems all fine for rtbc!
Comment #10
donquixote CreditAttribution: donquixote commentedI correct myself: "composer install" is meaningless.
But "composer update" has the same effect with or without, except for the magic random suffix and composer.lock.
Comment #11
webchickAwesome-sauce! This patch makes me very happyyyyy! :D :D
Committed and pushed to 8.x. Thanks!
I did have one question though, which is whether or not the "8" suffix there makes sense. It means we need to remember to change this again in Drupal 9. Is this nomenclature common in other composer-ish projects, or is "Drupal" sufficient? If so, could we get a quick follow-up for that?
Comment #12
donquixote CreditAttribution: donquixote commentedThe goal of this suffix is to avoid name clashes if more than one composer instance is at work. The more unique this name is, the better. The simple logic here is that "Drupal8" is more unique than just "Drupal". Anything beyond that would not be possible, because all we know at this point, for a hardcoded suffix, is that we are in Drupal 8.
By default, this composer.json setting would be empty, and Composer will generate a random string instead. But these projects don't put the vendor stuff in a git repo. Not even in your local application/site repo.
You are supposed to run
composer installorcomposer updateafter every git checkout.But Drupal is special, because it has all the vendor/ stuff in the main repository.
I imagine or hope that in Drupal 9, and the vendor/ stuff will no longer be in the same repo with Drupal core.
If this is not the case, we will have AutoloaderInitDrupal9, which means it will be possible (theoretically) to have some stuff from a Drupal8 instance, and some other stuff from a Drupal9 instance, in the same request. Probably going to break anyway, but then at least we can't blame the AutoloaderInit suffix.
If we had a more unique suffix, e.g. AutoloaderInitMySiteDrupal8 vs AutoloaderInitOtherSiteDrupal8, then we could even have stuff from two Drupal8 instances in the same request. But this is not possible, because we can only have one suffix in the repository.
Hope this makes sense :)
Of course we could still say "nah", this is ugly, we don't like it, let's name it to just "Drupal". It won't be a big loss.