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.
