Use native composer autoloader

[mvorisek]

In #9407 and #9412 composer autoloading was introduced to coexist with the legaly autoloader.

This PR replaces the legacy autoloader so composer is newly needed.

[alecpl]

What's the reason for replacing composer.json-dist with composer.json. On upgrade we can't just sync that file. It will remove all plugins/skins/packages added by the user.

[mvorisek]

Yes, upgrade script is the last place with composer.json-dist. The reason I renamed the file is only composer.json is read by packagist/composer installer and this repo is impossible to be used as a roundcube/roundcubemail dep in other projects otherwise. I would be grateful if you can help me with migrating the upgrade script, probably we want to copy the composer.json as composer.json-dist or rename the current composer.json before the upgrade is started.

[mvorisek]

I have reworked/simplified this PR to update the autoloading only, eg. to replace the custom autoloaders in favor of native composer autoloader. The advantages are summarized in the PR description.

[alecpl]

Ok, less contentious, I guess, but still

1. We need to move/merge "autoload" and "autoload-dev" sections into composer.json in here

   roundcubemail/bin/update.sh

   Line 177 in 98ac6e0

   if (is_file(INSTALL_PATH . 'composer.json') && is_readable(INSTALL_PATH . 'composer.json-dist')) {

2. As this might be a BC break for some plugins, I'd have to make some more tests, to find out what the impact is.
3. I'm not sure, but this might be a problem for Roundcube packages in distros like Debian, but I don't really know.
4. Will that work at all when using "Dependent" (non-complete) Roundcube package to upgrade your installation? I.e. will bin/ scripts work without composer.json file and vendor folder? I guess it will not work. Does that mean we have to stop providing "Dependent" Roundcube packages?

[alecpl]

FYI, I know two plugins that depend on rcube_autoload. It's our managesieve plugin, and external sauserprefs plugin.

[mvorisek]

PR is done, all autoloaders are migrated to native composer.

External plugins needs to be updated if they do not utilize native composer already.

[johndoh]

Not everyone uses composer to install plugins, not everyone can, not everyone has command line access to their hosting or is confident enough to use it. This PR prevents those people from being able to use internal or external plugins which use the autoloader.

Please consider retaining the Roundcube autoloader or do something else to maintain the functionality of plugins used in none composer environments.

If Composer is to become a requirement then please update the documentation e.g. https://github.com/roundcube/roundcubemail/wiki/Plugin-API#installing-and-activating-plugins to reflect this and also what simply adding the plugin name to your config file is no longer enough to enable internal plugins.

[alecpl]

Internal plugins should be in "require" not "require-dev", I suppose. Anyway, I'm not sure I like such a big composer.json file. I'd prefer to keep it simpler. More complicated it becomes, more error-prone updates become.

I understand it allows to remove some code in tests, but other than that it's not a big win. That part regarding plugins, I mean.

As for the general autoloader, I like that part. That being said, I would accept this only for Roundcube 2.0. We might decide to go with 2.0 instead of 1.7 if we merge other breaking changes, specifically #9294.

[mvorisek]

Internal plugins should be in "require" not "require-dev"

The plugins are not hosted on Packagist, ie. composer require roundcube/roundcube would fail otherwise. repositories composer config is for composer root package only.

Other reason to keep them in "require-dev" is to allow plugins customization using composer in child packages.

Becauose of this I belive it is wanted to the bundled plugins listed in "require-dev". For distribution/downloads, the roundcube/roundcube is a composer root package, so nothing changes.

Not everyone uses composer to install plugins, not everyone can, not everyone has command line access to their hosting or is confident enough to use it. This PR prevents those people from being able to use internal or external plugins which use the autoloader.

I support this. I will rework this PR to keep the old autoloading working. I am fairly confident it can coexist until v2.0 at least.

[mvorisek]

I have reviewed the removed/replaced original autoloader methods.

Let's separate the autoloading to two domains.

ROUNDCUBE INTERNAL AUTOLOADING - all autoloading code loading files withing this repo. With this PR, such loading is replaced with composer native autoloading mechanism.

There any many advantages, it is faster, more secure, static analysers can rely on "descriptive autoloading", and it also allows to use this package as a dependency easily.

The "disadvantage"/BC break is composer is needed. I do not think this is a problem as long as the "composer update" is run before the files are packged and distributed. This is already done for "complete distribution bundle" - https://roundcube.net/download/.

Not everyone uses composer to install plugins, not everyone can, not everyone has command line access to their hosting or is confident enough to use it. This PR prevents those people from being able to use internal or external plugins which use the autoloader.

With this said, composer autoloader is fine to be used for v1.7/master. Composer files are distributed and no composer is needed for the install (on hosting).

CUSTOM PLUGIN AUTOLOADING - autoloading of files outside this repo. The preferred autoloading is using composer for the same reason as for internal files. However, I agree with #9241 (comment) above, currently the Roundcube does not require composer to be installed/rerun when a plugin is added and it should stay so.

This has been fixed in fd0d669. AFAK the plugin main file (file named like the plugin directory) is kept loaded by Roundcube as before and if the plugin relies on autoloading using custom set_include_path like enigma did - https://github.com/roundcube/roundcubemail/blob/7713b7c1bd/plugins/enigma/enigma.php#L109 - it is kept supported as well.

With this said, I belive this PR can be landed. Feel free to test this PR and let me know if there are any concerns.