vendor directory based typo3 installation

[KampfCaspar]

Hi!

I propose to enable a typo3 installation in 'composer mode'; meaning everything automatic goes into the vendor directory. Like the linked branch, that switches to 'vendor directory mode' if the 'extra' 'typo3_vendor_based' is set.

Why?

Because eveything outside of 'vendor' is supposed to be editable, i.e. NOT composer influenced. I don't like composer messing in MY sources ;)

That's also why I changed the installation target for composer-installed extensions (typo3/ext). I know this 'mixes' two different vendor directories, but isn't creating a third destination (a common ext directory used by core and extensions) worse?

In my preliminary tests, I could easily set up a typo3 site with 'only' a link to typo3 core messing in my sources and all extensions linked as system extensions.

Of course, I'm open to improvements/suggestions.

KampfCaspar

[fschwaiger]

How about installing all the extensions into the vendor directory and then symlinking them in typo3conf/ext? Something like vendor/typo3/ext for extensions alongside vendor/typo3/typo3 for the sources.

[KampfCaspar]

I would really like to leave typo3conf/ext for non-composer-managed extensions - that may exist alongside those managed by composer from TER. The user is still able to disable those or install updates in typo3conf/ext.

What I'm undecided is whether symlinking directly into typo3/ext (and therefore violating the core's vendor directory) is really better than establishing a new directory to collect symlinks to extensions which is itself symlinked from typo3/ext.

[tmaroschik]

Thank you for your initiative on this topic. With the first iteration of the composer integration we're on the road to TYPO3 Flow folder structure parity. Further we want to limit the possible deployment options to common ones in order to keep the code complexity in the core and installer low. This goes into the same direction like the system environment checks in the install tool that will alert if you don't converge to those. Of course you're free to fork the installer and override it in your installations root composer.json. Thanks for your understanding.

[pniederlag]

As composer user I expect common composer behaviour, which means the actual content of dependencies is out of scope of the application source and does go into vendor/ or whatever place is assigned, tracked only by a distinct ref. As TYPO3 developer and git lover I expect typo3conf/ext to be part of my app managed by git and fight the submodule state of being. As TYPO3 admin I know there are even things like the EM that fiddle with typo3conf/ext as well.

Not an easy task in terms of single source of truth.