disclaimer, my “evil” long term plan could be to get rid of package names and refer to packages only by composer name in the future, mostly for consistency. Although I understand that would be a huge change it certainly will take a long while to unfold. In that regard I see a lot of places where this would come in handy.
Now to the actual discussion topic at hand. Settings currently are nested structures starting with upppercase package key “segments”!
Now this is all nice and fun, but then you add a package
Neos.Fusion.Form and suddenly you need settings in
Neos: Fusion: Form:
That also works quite nicely but it means that suddenly the settings of Neos.Fusion contain a new key
Form, that doesn’t have ANY relation to the Neos.Fusion settings and should not even show up if you request all Neos.Fusion settings (hint: it does). Also means if there is a schema defining which keys are allowed for the Neos.Fusion settings (a sensible help to understand wrong settings) then that schema in Neos.Fusion suddenly needs to “know” about the new key that is not even relevant for that package. IMHO that’s all very messy.
For reference this change: https://github.com/neos/neos-development-collection/pull/2885
The obvious solution would be to treat the package name/key as a solid identifier and not split it, so that each package settings is fully separate from each other. So with our current way that would look like this:
'Neos.Fusion': someSetting: abc 'Neos.Fusion.Form': anotherSetting: foo
That could obviously as well become the composer name at that point:
'neos/fusion': someSetting: abc 'neos/fusion-form': anotherSetting: foo
Now in either case that would be a severely breaking change and I would like to start discussing ideas on how to get to this nice separation while being at least somewhat less breaking
The following things would AT LEAST be breaking in this case, just to mention them:
Third party packages would have to adopt this or they wouldn’t work / overwrite settings at all.
accessing settings by path would fail as now the path is different / inaccessible because we cannot do the quoting in our path string (
'Neos.Fusion'.someSetting the latter wouldn’t work, but the composer name version should)
If you rely on those “sub” package settings to be there that would fail.
THere could be a completely different way of doing this separation than shown above, it’s just a possible way to solve the root problem, give me alternative ideas if you have any!