D8 strategy for Drush

Currently you need

\Drupal::service('composer_manager.manager')->registerAutolaoder();

in a drush command due to #1955386: Automatically register Composer's autoloader early in the bootstrap process to improve DX

I don't yet understand the issue well, but Drush's earliest hook is hook_drush_init(). Can you solve this by putting \Drupal::service('composer_manager.manager')->registerAutolaoder(); there?

As far as I can tell, it's too late for my use case, where Drush begins bootstrap, starts to rebuild entity type static caches, then fails (since I have an entity type implementing an interface only reachable from the other autoloader):

    0.0146    2507864   2. drush_main() /home/vagrant/.composer/vendor/drush/drush/drush.php:16
    0.2096    7091768   3. _drush_bootstrap_and_dispatch() /home/vagrant/.composer/vendor/drush/drush/drush.php:68
    0.3648    7097144   4. drush_bootstrap_to_phase() /home/vagrant/.composer/vendor/drush/drush/drush.php:94
    0.5884   20968096   5. drush_bootstrap() /home/vagrant/.composer/vendor/drush/drush/includes/bootstrap.inc:308
    0.5901   20970264   6. _drush_bootstrap_drupal_login() /home/vagrant/.composer/vendor/drush/drush/includes/bootstrap.inc:185
    0.5904   20970496   7. drush_drupal_login() /home/vagrant/.composer/vendor/drush/drush/includes/bootstrap.inc:932
    0.5921   20997888   8. user_load() /home/vagrant/.composer/vendor/drush/drush/includes/drupal.inc:154
    0.5996   21756520   9. Drupal\Core\Entity\Entity::load() /var/www/site/docroot/d8/core/modules/user/user.module:288
    0.6073   22247296  10. Drupal\Core\Entity\Entity::getEntityTypeFromStaticClass() /var/www/site/docroot/d8/core/lib/Drupal/Core/Entity/Entity.php:427

I've tried to read through the bootstrap code, but found it difficult to grasp, since it tries to accommodate multiple core versions. Perhaps what we need to do is add an earlier hook.

Crossposting https://github.com/drush-ops/drush/issues/718 here

This is not a problem specific to Drush. Same happens with core/rebuild.php.

In the first place, the problem is that the request event to which composer_manager subscribes to register its autoloader is not fired until the request is being dispatched at HttpKernel::handleRaw().

@pcambra ad me have been working in trying to fire the request kernel event (in rebuild.php and drush) so the autoloader gets notified earlier. We got it but other subscribers to the event try to do things assuming all modules are already loaded (namely PathSubscriber.php tries to get path of 'public' file scheme, but file schemes are initialized to void since file module is not loaded yet). Here's a patch with our work on rebuild.php for reference: https://gist.github.com/jonhattan/84f52cfeb06868cc6ade

Possible solutions:

1. In composer manager. Drop the event subscriber and require the autoloader in settings.php (Per hook_boot() change record).

2. In core. Propose a new event that fires earlier. For example "aferboot" or "prerequest" at Drupal::Kernel::handle.

3. In core. Ask someone. Put an eye on autoloader related issues and wait for some resolution. Possible related:

* #2023325: Add interface for classloader so it can be cleanly swapped
* #2253593: Stop classloader searching filesystem for classes before drupal_classloader() is called
* #1241190: Possible approaches to bootstrap/front loading of classes
* #1818628: Use Composer's optimized ClassLoader for Core/Component classes

I can confirm that require 'sites/all/vendor/autoload.php'; in settings.php fixes the issue.

@chris - what do you think of requiring autoload.php in settings.php per #9? maybe thats a temporary workaround?

This will be resolved by #2350639: Rewrite 8.x-1.x, since composer_manager will stop having its own autoloader.

Thanks for the feedback and the help in identifying the underlying causes.