See #10024 (comment) tho :)

But yeah, while the situation with updates isn't ideal and may lead to broken processes, it's maybe better than the current situation.. I am not sure really.

I read that, but I miss reasons why to understand this feeling you express in that comment :)

Well.. there is #10024 (comment) showing an example scenario.

Another scenario that could break is like:

• Package A has func.php autoloaded, declaring a bunch of functions.
• It gets autoloaded, then updated in the same process to a new version which renamed to functions.php
• when autoloading it again, functions.php is now included, and include_once won't save you there, and you get a fatal because of redefined function..

Plus the fact that these files were never loaded during composer runs, and now they would be, and that may trigger all sorts of unforeseen effects.

So I'm not 100% against, but it is not without risks, and I'm not sure it's worth it.

Another scenario that could break is like:

• Package A has func.php autoloaded, declaring a bunch of functions.
• It gets autoloaded, then updated in the same process to a new version which renamed to functions.php
• when autoloading it again, functions.php is now included, and include_once won't save you there, and you get a fatal because of redefined function..

don't we have the same issue with class autoloader? when a plugin use a class that is updated?

Not really because the class is already in memory and it won't be loaded again. Sure you may have problems if the code changed massively and is not compatible anymore, but that's something we really cannot fix. Plugins should thus ideally be rather self-contained as much as possible.

sounds like the same edge case.. one could changes code of a class, adds methods, changes interface signature...

If it worth it for classes, I believe it is the same for functions/polyfills

Plus the fact that these files were never loaded during composer runs, and now they would be, and that may trigger all sorts of unforeseen effects.

Indeed, this is the major risk of this change.

It gets autoloaded, then updated in the same process to a new version which renamed to functions.php

Maybe plugins shouldn't be allowed to have a "files" section, but their dependencies should?
The linked issue is quite annoying to say the least. It almost kills the concept of polyfills, in the generic sense.
This risk for updates is just a fatal error that can be worked around by restarting the process (maybe after deleting vendor/), isn't it? I feel like this is an acceptable tradeoff.

Indeed, this is the major risk of this change.

I don't think it is: those files are autoloaded for regular runs without such issues.

Ok, maybe we can try it out for 2.2, but I think it's too risky to smuggle this as a bugfix.

Works for me, PR rebased.

What worries me more with such change aren't polyfill packages for which the files are included, but the fact that literally anything can be done in these inclusion files, as there is no specification for that. While one could of course include side effects in class files as well, doing so (IIRC) violates the PSR-4 specification.

But we indeed will not find out without trying how much will break. Hopefully we're lucky.

literally anything can be done in these inclusion files

This is true, but this is not specific to plugins. Regular auloaders already load those files. The plugin's autoloader has nothing specific to care about on this topic.

literally anything can be done in these inclusion files

This is true, but this is not specific to plugins. Regular auloaders already load those files. The plugin's autoloader has nothing specific to care about on this topic.

There is quite a difference between runtime inclusion of the autoload file and building a temporary autoloader on the fly during Composer build time.

One example Jordi gave before is renaming the inclusion file and declaring the same symbols during update.

In previous Composer versions composer updates failed likely, when a plug-in was updated with incompatible classes. Now the update process is much more likely to fail for any dependent package changing autoload includes.

Anyway. We'll see where this goes. Maybe it'll be fine

I belive this is a bug and files autoload should work everywhere. Nice example are php polyfill scripts or other global config/declarations.

So 🚀 from my side. If execution of plugins can be easily detected, please post the condition here so developers who did not want files autoload feature in their scripts can use it.

Thanks!

Is this causing the issues in #10277 ?
I'm getting various autoload errors on Laravel and Magento2 projects.

Magento2 uses the file autoloader for module registration, but that seems to rely on having the normal namespaced autoloading available.

@barryvdh yes most likely, please try with the latest snapshot it was just fixed in #10279

This fixed my issue with Laravel, but not with Magento 2 unfortunately.

$ composer --version
Composer version 2.2-dev (2.2-dev+0662fa2662b6bb7d683aaaf89e4ec3dfb5e833f6) 2021-11-12 08:44:34
$ composer update
PHP Fatal error:  Uncaught Error: Class 'Magento\Framework\Component\ComponentRegistrar' not found in /var/www/project/app/code/MageB2B/Staff/registration.php:9
Stack trace:
#0 /var/www/project/app/etc/NonComposerComponentRegistration.php(29): require_once()
#1 [internal function]: Magento\NonComposerComponentRegistration\{closure}()
#2 /var/www/project/app/etc/NonComposerComponentRegistration.php(31): array_map()
#3 /var/www/project/app/etc/NonComposerComponentRegistration.php(34): Magento\NonComposerComponentRegistration\{closure}()
#4 phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php(1419): require('/var/www/project...')
#5 phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(206): Composer\Autoload\composerRequire()
#6 phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(425): Composer\Plugin\PluginManager->registerPackage()
#7 phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(87): Composer\Plugin\PluginManager->loadRepository()
#8 phar:///usr/local/bin in /var/www/project/app/code/MageB2B/Staff/registration.php on line 9

@barryvdh please report an issue with more details how one can reproduce this. I'm assuming it's an issue with a magento package/plugin not requiring all its dependencies though..