Is there a special reason why $supportedTypes is private instead of protected?

[hctom]

I was trying to create a custom installer plugin by extending this package's Installer plugin class, but I had to realize that this won't work without duplicating almost all its code. You are not able to override $supportedTypes property in the extending class due to its private handling. So it is impossible to register custom types and use the same base logic.

Is there any special reason why the property has the private flag? Otherwise this should definitely be changed to protected to allow much easier development of custom installer plugins. E.g. the BaseInstaller class handles its $locations property like this to allow easy extending and overriding.

With this simple change it would be possible to create custom installer plugins with classes as simple as this:

namespace Composer\Installers\Custom;

use Composer\Installers\Installer as ComposerInstaller;

/**
 * A custom Composer installer.
 */
class Installer extends ComposerInstaller {

  /**
   * Package types to installer class map.
   *
   * @var array
   */
  protected $supportedTypes = [
    'my-custom-type' => 'MyCustomTypeInstaller',
  ];

}

I'd appreciate your feedback. If this is something that's worth changing, I'll provide the necessary pull request.

[Nik Samokhvalov]

Hi! If I understand you correctly, you need add your Composer Installer to Composer\Installers\Installer::$supportedTypes.

https://github.com/composer/installers/blob/master/CONTRIBUTING.md#creating-a-new-installer

[hctom]

Thanks for the documentation link, but I already knew that one ;) In my case, the installer plugin is not worth contributing, because it deals with a totally custom/special case... But IMHO it should be possible to write a custom plugin for your own project and leverage the existing code as a basis - which is not possible right now.

[Jordi Boggiano]

I'm not so sure this package should be a base to build extensions on. I kind of disagree with that approach as it's way overkill if you want to write a custom installer to pull in this whole package. You can do this fairly simply by extending LibraryInstaller, overriding getInstallPath and supports with super simple implementations should be enough.