Package key naming scheme for site packages

Continuing the discussion from Migrating to

Also a good idea.

At Flownative we use the Vendor.WwwFullDomain scheme like we did in the past in the Neos project (TYPO3.NeosDemoTypo3Org etc.). Are the strong arguments in favour of the one or the other?

Yeah my naming scheme comes from our networkteam convention.
We do it like: Vendor.Projectname.TypOfPackage
Especially for multi domain installation we like the idea of having a clear naming which shows, that something is a site package by naming it .Site at the end and keeping the name inbetween as short as possible as domains might change but project names will stay consistent.

I don’t really see the advantage of adding the ‘Site’ suffix in our case as we always keep the site packages in the main distribution and don’t have them in separate git repositories. If we would have that I would see the usecase though :wink:

In our case we name the site package to the project, so ‘Vendor.ProjectName’ or whatever name the customer uses for the site. We tried to embrace the domain name naming scheme, but that just didn’t work out and does feel nice tbh.

1 Like

I can live without the naming of .Site at the end but I would be in favor of finding a convention without having to use such long Names as DemoNeosTypo3Org. I totally dislike such long camel cased names as they are really hard to read and type. And as the package name will be used in any path and node type name it should be easy to read and type. I could imagine that the basis for the basic site package is something like Neos.NeosIO and if subdomains will be added and need package names it could look like Neos.NeosIo.Subdomain. So for a demo website with the url it would be Neos.NeosIo.Demo. What does the rest think?


Just my 2ct: I really like your idea for humans, but in my opinion it makes it a bit more difficult for automated hosting environments: for scripts it is nice to just strip “.” from the full domain, prepend it with a vendor / customer name and there you have your site package key.

But I think I’m fine with either solution.

So, what does everybody think? Which pattern should we use in the Neos project and thus promote as best practice?

  • Neos.NeosIo.Demo
  • Neos.DemoNeosIo
  • Other pattern

0 voters

Poll closes on Wedneday, 8.7.

Two general remarks here:

I don’t like using the domain name in the package name that much because it could change or the primary domain could change or, or, or. Secondly I still think it is NOT a good idea to propagate putting the site package in one repository with the distribution. I might open another topic for this discussion, but we work around composer with this and I am sure that will bite us in the future :wink:

In case of the Neos website I would strictly want to vote for keeping the site package in one repository with the distribution. I always hated the solution with different packages it was complicating and I personally don’t see any disadvantage in using it the way Robert set it up now.

1 Like

That’s true and the main drawback I see is that dependencies of the embedded package need to be repeated in the main composer.json and the package composer.json as well to satisfy Composer and the Flow package manager (for correct package dependency ordering).

Maybe we could find a way or propose a feature for Composer to allow for a locally installed package (in a subdirectory) that is correctly tracked by Composer.

1 Like

Hey everybody,

I’d also like to try to “fix” the issue in composer or a composer plugin – would really like that :smile: And then have just a single repository because that is extremely convenient.

All the best,

Ok, maybe we can discuss it at the code sprint. IMHO it would be important to have a consistent composer.lock AND composer autoload information even if we don’t use it now.