cakephp / bake

The Bake Command Plugin
Other
111 stars 101 forks source link

Plugin generation shouldn't include composer.json & phpunit.xml by default #998

Closed markstory closed 4 weeks ago

markstory commented 3 months ago

Description

The default behavior of bake plugin is to create an application plugin. However, plugin bake also generates phpunit.xml.dist and composer.json which are redundant for in-app plugins.

Adding a --standalone option to bake plugin would allow us to skip generating composer+phpunit configuration for in-app plugins but retain that behavior for standalone plugins.

Related to #991

dereuromark commented 3 months ago

The Alternative would be to add --vendor to put it into a vendor folder directly and adding those files. And otherwise skip them. The flag --standalone could also be understood as vendor standalone compared to plugin and App related and might be a bit unclear.

LordSimal commented 1 month ago

Wit the addition of https://github.com/cakephp/plugin-installer/pull/64 the composer.json is NOT only needed for publishing the plugin on packagist but it instead moves the autoload namespace to the plugin itself.

Therefore removing it from the default template is not needed anymore.

phpunit.xml.dist on the other hand could easily be removed imho. especially since the only parts special inside that file are the testsuite definition and the PHPUnitExtension for the fixtures.

ADmad commented 1 month ago

..but it instead moves the autoload namespace to the plugin itself.

No it doesn't. That change is related to composer config of the app, it has nothing to do with the composer.json within the plugin itself.

So generating composer.json is still redundant for in-app plugins.

LordSimal commented 1 month ago

I thought you used the namespaces configured inside those composer.json but looking at that PR again it indeed just uses the folder name inside plugins as the root namespace for that plugin.

With that I can agree, that the composer.json is actually doing nothing out of the box.

As long as that plugin name doesn't colide with another vendor namespace this seems fine by me, but it would still be a bit more configurable to actually define the plugin namesapce inside the composer.json of th plugin.