Configuration might be unordered by underlying filesystem

[mhsdesign]

In neos/neos-ui#3560 (comment) i experienced an inconsistency where the NodeTypes would show up in different order in the Node Creation Dialog on different systems. Always in an unorder per system. But each different.
Thats because the underling directory scan via the RecursiveDirectoryIterator doesn't enforce a specific order, but will return the files how the underlying file system returns them - on linux - unordered.

This describes of course a Neos problem. Thats why i created a bugfix for Neos: neos/neos-development-collection#4394 (Which would fix the described NodeTypes configuration folder problem)

But as part of a bigger picture it was pointed out that this kind of unorder will also happen in other cases:

I had an interesting discussion with @gjwnc first here and then continued here about the unorder in other parts of neos and flow.

None of the configs is or was sorted. Not the nodeTypes or Settings or Policy. Before neos/neos-development-collection#3332, the config was mainly loaded using Flow's YamlSource::load. This one is using glob() which, regarding sorting, has the same behavior.
Regarding Settings or other yaml files you just often don't notice the difference between your various installations. This is because your package order introduces a "good enough" hierarchy which, after merging the yaml files, results in, apart from sorting, the same yaml config - e.g. you likely find the same values using the same path injecting a setting.
A very simple example to show the unsortedness can be ./flow configuration:show itself. If you have many packages, it is likely that there is a difference in the results from your local dev and production. I don't mean a difference of existing/not existing packages because of require-dev, I mean that the order of settings is just different also for packages existing on both installations.

A quick check on a project of ours showed, that on production I get

PunktDe:
    EditConflictPrevention:
...
Sandstorm:
    TemplateMailer:

and on my local dev it is reversed - Sandstorm before PunktDe.

---

Regarding configuration I think it would be great to have consistent and predictable results.
I would also go one step further and sort the packages and loaded yaml source, i.e.

1. Add \ksort($this->unsortedPackages); to PackageResolver
2. Add \sort($pathsAndFilenames) to YamlSource

This should result in predictable results for all installations and all configs. 😃 But yeah, not sure if there is any interest in such little changes likely no one will even recognize, thus maybe not much of a need 🙈 But I still favor predictability because it avoids future confusion.

Also @dlubitz chimed in:

Not sure if this is really an issue. The unsorted order can only happen within a package OR cross-package if no dependency is defined.

Within a package the developer has to ensure, that there are no concurrent configurations, which could lead to different results.

Cross-package you have to define dependencies anyways, as otherthings (e.g. Fusion) will break too.

BUT I would expect a loading order of the files by name within a package, too.

And so did @kdambekalns:

Basically all was said:

• sorting never happened on name so far
• within a package you should not need to rely on sorting by name
• packages are generally sorted by dependencies, must not be changed

Adding one thing I can think of:

• it might be good to have packages with same "priority" sorted by someting to be stable

Maybe we find the merged configuration order worth correcting, maybe not. Lets see.

[kitsunet]

Good good!