TASK: Introduce internal flow package key value object

[mhsdesign]

Upgrade instructions

Review instructions

The concept around the flow package key might be dated, still major parts rely on this and we could use a little strict typing around ^^

Also possible refactoring in the future to a composer key might be easier if phpstan can tell us the difference between the types instead of refactoring one string to another.

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

maybe we should take it down a notch

the motivation for this pr was that i have seen some custom package key implementations like
https://github.com/PackageFactory/atomic-fusion-presentationobjects/blob/3d7e04eec33e1136b7634f08bd4894e2e76daef6/Classes/Domain/PackageKey.php#L14 but i thought that flow itself should provide a value object to make also usecases in Neos.Neos easier.

i started to non-breaking allow the FlowPackageKey as union with string in methods like PackageManager::getPackage
to make the FlowPackageKey not only package management internal but also be usable from outside and possibly be used / returned by things like the Neos' site Site::getResourcePackageKey().

also i meant to use the FlowPackageKey value object for new (internal) classes in Neos.Neos like
(see neos/neos-development-collection#4933)

interface FusionAutoIncludeHandler
{
    public function loadFusionFromPackage(FlowPackageKey $packageKey, FusionSourceCodeCollection $sourceCodeCollection): FusionSourceCodeCollection;
}

But this requires us to also retrieve the FlowPackageKey value object somehow meaning $package->getPackageKey() should return it, as otherwise we would need to cast it manually: FlowPackageKey::fromString($package->getPackageKey()).

in the end it might be that we are better of keeping the apis only string based instead of tying it to the FlowPackageKey for these reasons:

• actually using the FlowPackageKey in all parts would require a breaking change and bigger refactoring
• in most places we dont really care that the format is Flow or Composer so it might be even easier to migrate to composer names when all apis just operate on the strings or one generic PackageKey dto.

so it seems what i really wanted to do was to create a PackageKey value object which for now has no validation so it supports both composer and flow style syntax. For now the proposed PackageKey would just always hold the Flow syntax, but we could already open up the api of the PackageManager to also accept and operate on composer package names.
... or we migrate first to composer while still being string based and later when we feel like we add and dto.

Either way i think its safe to say in order to get this merged and not delayed that the FlowPackageKey will be used FULLY internal and not leak to any public api.

[kitsunet]

Mmmm, the thing is PackageKey is "Flow speak" composer calls this package "name", this is not super stringent in our code but the respective parts dealing with composer names should be packageName, so I don't think it would be good to alllow both under the "PackageKey" naming. Maybe this could be a case for an extended class "PackageName" and then extended by "PackageKey" and in the future we could deprecate PackageKey when things works with PackageName (only) and then at some point make it final when ...Key is removed.

[mhsdesign]

Removed the new FlowPackageKey from the public api and also added a few unit tests to test the (partially odd) behaviour.

In the end this is just a nice little refactoring but not a feature.

[mhsdesign]

This is now ready to be merged. And i will refrain for now to extend this into a bigger refactoring, changing public api and adding a PackageName dto or things the like.

[kitsunet]

I don't necessarily like the public API of the new VO, but it's not worse than we had before 😆

[mhsdesign]

Aaaand i added nice unit tests so it should definitely be better than before :D