Volto add-ons naming convention

[cekk]

@tisto can you please recap here the naming convention that we decided for volto addons that are not in the core? Both from backend and frontend.

We should also add this to the documentation.

These are two repository examples that we made for one current project:

• https://github.com/collective/volto-cookie-banner (Volto component)
• https://github.com/collective/collective.volto.cookieconsent (Plone add-on)

Then there is the npm organization problem.

I created the backend one with collective.volto.* namespace to indicate that is a collective package for volto (not core).

[tisto]

For frontend:

@collective/volto-my-package (for this we would need to get access to the @collective account on npm

For backend:

collective.volto.my_package

We have to think about an alternative for the frontend, so I'd just go with volto-my-package then...

[sneridagh]

Just my 5c, There are already some resources written: https://docs.voltocms.com/addons/best-practices/

NPM support searching by keywords: https://www.npmjs.com/search?q=keywords:volto-addon

and just searching by the keywords also works.

The awesome-volto repo as source of truth is also handy, I've seen far too many attempts to make "add-on databases" raise and fail, and seems that the awesome- format works through the industry.

Having all this in mind, I think that have a recommended way is good to have and document it in the docs. So, start the add-on with volto- as we are already doing is fine (at the end, the "collective." is also a prefix). Putting effort into the npm keywords is fine too.

Going farther than that, it's like trying to put walls at the countryside. And given the record of current naming schemes it shows clearly.

Regarding core add-ons (if any), then let's use the @plone organization. Given how NPM orgs work, I don't see any value into using one for the collective NPM packages (like @plone-collective one)... Also, let's keep the vanity org use for companies.

[avoinea]

Regarding core add-ons (if any), then let's use the @plone organization. Given how NPM orgs work, I don't see any value into using one for the collective NPM packages (like @plone-collective one)... Also, let's keep the vanity org use for companies.

I agree with @sneridagh and I think we all agree that the @plone namespace is reserved for the core libraries and add-ons released and maintained by the Plone Core Teams.

Now, the purpose of collective namespace was before (in the python world), and I think it will be (within the JS world), to protect popular Plone/Volto add-ons from becoming un-maintained and then having to fork them, rename/re-brand them in order to make them work with the latest versions of Plone/Volto.

I'm totally against encouraging people to release add-ons on npm without a namespace, as in the end, we will have old/unmaintained add-ons and later released add-ons like: volto-block-accordion-2028, or people will start adding their org/name within the add-on name like: volto-eea-accordion-block, volto-collective-accordion-block.

For now, I would encourage people to release Plone/Volto add-ons under their own namespace, this way we:

• avoid collisions and add-on name reservation by "clunky" add-ons.
• can have multiple add-ons for the same purpose and give people possibility to choose.
• can fork an add-on, customize it, and release it under own clients namespaces to fit their needs (I'm not sure I should encourage this practice :smile: )

If the add-on is generic enough, and it will remain generic then people should summit it to @plone-collective, @plone-addons umbrella where a larger group than Plone Core Team can review, release and maintain LTS.