CMS Fluid has hidden dependency on CMS Backend
It is technically possible to install `typo3/cms-fluid` without also installing `typo3/cms-backend`, but classes in `typo3/cms-fluid` in some cases depend on classes from `typo3/cms-backend` not just in runtime-executed code but also in documentation-specific code, e.g. using instances of `UriBuilder` in `f:uri.page`.
Doing such a limited install, for example when automating XSD schema generation, causes an error unless you explicitly add `typo3/cms-backend` as dependency.
Is an issue in all branches that use split tree. However, 8.7 does not use those third-party classes in the VH argument registration methods and so is safe to at least generate XSD schemas for. Hence, relevant TYPO3 version is set to 9.x.
#2 Updated by Christian Kuhn over 1 year ago
Well, I think we added only "hard" dependencies until now to composer.json in our core extensions. For instance, if your extensions primary job is a backend module for editors, but it also comes with a tiny frontend plugin, we until now only set cms-backend as dependency, cms-frontend could be a suggest then.
This is similar for typo3/cms-fluid: Only a couple of VH's really need cms-backend, "most" of cms-fluid works well in practice if cms-backend is not there. However, since cms-backend is a hard requirement for a full typo3 anyway, it does not matter much. Thus, I'd be fine to add cms-backend to the require section of composer.json in cms-fluid. And I'd guess same goes for cms-frontend (needs check). It simply does not make much sense to use cms-fluid if not at least one of the two is loaded. In a project that does not need cms-frontend and cms-backend, one would probably go with standalone typo3fluid/fluid only in the first place and not with the typo3 cms part on top, even if cms-core is loaded, which then would act as a library only. And in fact cms-core is evolving to a library more and more since most controllers are in cms-frontend and especially in cms-backend and we're also slowly trying to push this further.
The only thing we could argue is whether we set cms-backend and maybe cms-frontend as suggest instead of require. That could be an advantage for frontend nodes that don't install cms-backend, or backend nodes that don't install cms-frontend. However, I'm not sure if the system is far enough already to do this in a good way already. But if we set require to cms-backend right now, it may later be turned into a suggest only for that reason.