neos / composer-plugin

Neos composer install plugin

Flow Composer Plugin

This package provides a custom installer plugin for Composer which handles the specialities of installing Flow packages.

It will handle packages that have a type of neos-* or typo3-flow-*.

Package package name

The Flow package name for a given package is determined like this, on order:

• composer manifest extras.installer-name
• first PSR-0 autoloading namespace
• first PSR-4 autoloading namespace
• Composer manifest extras.neos.package-key
• Composer package name (Does not work in all cases but common cases should be fine – foo/bar => Foo.Bar, foo/bar-baz => Foo.Bar.Baz)

Installation location

Where the package will be installed, depends on the Composer type suffix:

• plugin go into Packages/Plugins/{flowPackageName}
• site go into Packages/Sites/{flowPackageName}
• boilerplate go into Packages/Boilerplates/{flowPackageName}
• build go into Build/{flowPackageName}
• package go into Packages/Application/{flowPackageName}
• package-collection go into Packages/{flowPackageName}
• * go into Packages/{camelCasedType}/{flowPackageName}

composer-plugin's Issues

"ExcludeClasses"-settings option no longer valid

As of Flow version 3.0.0 the "TYPO3.Flow.object.excludeClasses"-setting is no longer valid and has been replaced by "TYPO3.Flow.object.includeClasses".

I would like to create a PR and fix this by completely remove the Settings.yaml (as it doesn't fulfill anything more than exactly this)

See Flow Changelog Entry
See Flow Issue #103

Error in Configuration validation since Flow 3.x

Hi there,

the configuration option excludeClasses has been deprecated in Flow, but is still used in this package. This causes ./flow configuration:validate --type Settings to recognize this as an error:

Validating Settings configuration

1 errors were found:
 - Settings.TYPO3.Flow.object.excludeClasses -> This property is not allowed here, check the spelling if you think it belongs here.

Require PHP 7.1

Since the new release 2.1.0 uses void return types in the Plugin class, the composer.json should require PHP 7.1+, the PHP version which introduced this feature. Otherwise this change breaks installations that still use Flow 4.x or older in combination with PHP 7.0 or older.
(Maybe not of the highest importance since it only concerns unsupported versions, but it would be an easy fix.)

Composer v2 Plugin Compatibility

Jordi wrote:

As we are getting Composer 2.0 closer and closer to a stable release,
and would like to get more people involved with testing it, it is
quite important to get the most common plugins to support our 2.0
branch. Otherwise many users will not be able to try the latest
Composer snapshots when we switch them to 2.0.

• Get composer's 2.0 branch easily using this phar file
  https://seld.be/composer2.phar (sha256sum is
  b7863783a37cea776d4eeab7843f4e968021456ce6df01358ce9c2cc85f3247a)

• Set up a trial project requiring your plugin from a local path repo
  so you can easily work on it and iterate, e.g.

   "repositories": [
       {"type":"path", "url": "../../my-plugin"}
   ],
  

• Change your plugin's composer.json to require composer-plugin-api
  "^1.0 || ^2.0" (to begin with)

• Update your main plugin entry point class to implement the new
  PluginInterface methods, see e.g.
  composer/installers@d2a9832#diff-e236c450b11f27e4bb81a5069bc619bc

• Run php composer2.phar update in that trial project to play with
  your plugin using Composer 2, and fix any issues you run into.

• If at all possible, releasing a version which supports both
  composer-plugin-api ^1.0 and ^2.0 is the best option really as that
  will allow people to use whichever composer version within a project,
  and makes the transition smoother. I am sure the more involved plugins
  will not be able to do this but I think for most it should be
  possible.

• Finally, report issues to us at
  https://github.com/composer/composer/issues if anything is broken or
  unclear, we'll try to help out ASAP. There is no changelog nor
  migration guide yet sorry about that, but I think most plugins don't
  really integrate so tightly with Composer that they will need it.

composer.json's "support.issues" is no longer up-to-date

As i see it, there is no "https://jira.neos.io" anymore and the issue tracker is now on github, would like to change this to "https://github.com/neos/composer-plugin/issues" in composer.json.

Plugin breaks composer status command

In any Flow setup run composer status, either v1 or v2 to see an error:

$ composer status -v


  [ErrorException]
  chdir(): No such file or directory (errno 2)


Exception trace:
 () at phar:///…/composer.phar/src/Composer/Package/Comparer/Comparer.php:68
 Composer\Util\ErrorHandler::handle() at n/a:n/a
 chdir() at phar:///…/composer.phar/src/Composer/Package/Comparer/Comparer.php:68
 Composer\Package\Comparer\Comparer->doCompare() at phar:///…/composer.phar/src/Composer/Downloader/FileDownloader.php:307
 Composer\Downloader\FileDownloader->getLocalChanges() at phar:///…/composer.phar/src/Composer/Command/StatusCommand.php:118
 Composer\Command\StatusCommand->doExecute() at phar:///…/composer.phar/src/Composer/Command/StatusCommand.php:76
 Composer\Command\StatusCommand->execute() at phar:///…/composer.phar/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///…/composer.phar/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///…/composer.phar/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///…/composer.phar/src/Composer/Console/Application.php:281
 Composer\Console\Application->doRun() at phar:///…/composer.phar/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///…/composer.phar/src/Composer/Console/Application.php:113
 Composer\Console\Application->run() at phar:///…/composer.phar/bin/composer:61
 require() at /…/composer.phar:24

Since this issue is no longer caused by Composer itself (see composer/composer#7519) I debugged and found it's caused by our plugin not returning an absolute path in getInstallPath()

composer/installers conflicts

composer/installers#330

We should add a conflicts entry to our composer.json and do what is suggested in the comment...

and MAYBE think about removing support for typo3-flow-* packages in this installer to remove the conflict as the other one only cares about typo3-flow packages (and works as long as those have PSR-0 autoload entries).

Update composer-plugin-api

Composer complains about the composer-plugin-api version string:
The "neos/composer-plugin" plugin requires composer-plugin-api 1.0.0, this *WILL* break in the future and it should be fixed ASAP (require ^1.0 for example).