Discussion: Package names and Settings

Creating Neos & Flow Code
1

Hi all,

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”!

Eg.

Neos:
    Fusion:

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 :smiley:

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 vs. '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!

2

Hi Christian, i totally like this idea.

to make it less breaky we could alter the behavior of @injectConfiguration to require an explicit „package“ argument in old syntax if you want to use the old configuration structure which we can add with a code migration. That ensures the values are still read properly as long as the old way is only deprecated.

Also other parts of flow/Neos that work with package names like routing or resource://urls should be made tolerant for both cases for a while.

So that would mean three steps. Support composer names as equivalent to package keys. Then deprecate package keys for a while and only then remove them.

3

I actually find the good old package names more intuitive as you are always using them in Fusion, PHP and other wherever else. Only rarely you need to use the composer name.
And I don’t see how that would then improve consistency?

Regarding the schema, I wonder if it’s not simply possible to extend a schema. Then Neos.Fusion.Forms could just add to the existing schema to make it valid.

4

More consistent if we use composer names EVERYWHERE obviously… So down the road at some point, because then there is just one definite name for a package.

And yes, that schema extension is certainly possible, you still extend a namespace / scope as a side effect.

5

Ok understood. So then a Fusion prototype would look like this:

prototype(my/neos-package:Component.Something)

And the folder structure would be a bit different too and look like in the Libraries folder?

6

Yeah, I’m not soooo convinced of the composer naming thing. Since the composer name can be arbitrary, I always need to look it up. But regarding the other change to make settings package-scoped, yes, that definitely makes a lot of sense. No good idea how to deal with the major breakiness though :confused:

7

Interesting point. Not sure how to deal with the fusion namespaces. Makes sense to use the composer name there aswell but.