RFC: Allowing composer package names for resources


(Christian Müller) #1

Hi all,

as you might be aware I am on a quest to remove duplication and concepts that exist on a bigger scale if possible. One such thing are package keys. With the advent of composer we have composer package names readily available to identity any package we might have in an installation and juggling with two different keys is never a good idea. So I would like to start allowing composer package names in places where now only Flow package keys work. (Obviously with the long term goal to get rid of them in the far future).

One place that I find conceptually rather hard are resource URIs just because you cannot simply replace the Flow package key with the composer name. Eg.

resource://Neos.Neos.Ui.Compiled/Public/Styles/Host.css but
resource://neos/neos-ui-compiled/Public/Styles/Host.css . We could obviously just take the first path segment to recreate the package name., but I think package names without vendor are allowed, so something like mypackage might be a valid composer package name, which would result in:

resource://mypackage/Public/Styles/Host.css and at this point just using the first path segment (+host) would be wrong. So I am considering alternative ways to describe this:

resource://neos-ui-compiled@neos/Public/Styles/Host.css
This variant would work deterministically (take host + if exists user portion and separate by /), but you need to do string manipulation on the package name to create this, which I would obviously want to avoid so you can simply construct the resource URI manually (or maybe just a helper to generate it from a composer name?).

Alternative would be some kind of marker I guess:
resource://neos/neos-ui-compiled/!/Public/Styles/Host.css (split at ! host + everything before is the composer name, everything after is the file path). (We could obviously use an emoji or something to make it even clearer…

Any suggestions or opinions?

Actually just reading up on the spec it can be pretty much anything… https://getcomposer.org/doc/04-schema.md#name so I might need to reconsider using it, although I think many other packages depend on that name, so idk, some encoding could perfectly solve the issue as well and let us use those names. In that case an utility is obviously necessary.


(Bastian Waidelich) #2

Awesome quest, Christian!

huh, I wasn’t aware of that mismatch. Where do we configure that resource://Neos.Neos.Ui point to resources of the Neos.Neos.Ui.Compiled package?

According to the schema the composer name…

consists of vendor name and project name, separated by /

Couldn’t we just apply the PackageInterface::PATTERN_MATCH_PACKAGEKEY to detect a Flow package key and fall back to “resource:////” for composer names, as in: https://regex101.com/r/HMwqkq/2


(Christian Müller) #3

huh, I wasn’t aware of that mismatch

My bad will fix my post that was a typo.

We still wouldn’t know if there actually was a vendor in the composer name. Even going with the strict recommended definition of a name (lowercase, alphanumeric) we might or might not have a vendor, right? So either support only composer names with a vendor (so that include one slash) or we need some identifiable separator between composer name and path?


(Bastian Waidelich) #4

The Schema documentation states otherwise (see above)


(Christian Müller) #5

LOL, nevermind, my bad :smiley: