plone
Deprecate "project" configuration in Volto (`src/config.js`)
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer: Víctor Fernández de Alba (@sneridagh)
Seconder: Tiberiu Ichim (@tiberiuichim)
Abstract
The old fashioned "project layout" is discouraged, in favor of the "policy add-on package". There's nothing that limits to move all the config from a project to an add-on package.
Motivation
Duplication of concerns, unification of the developer experience. This will encourage also to move the project's logic to the policy add-on as well and keep the boilerplate empty and expendable. This will help upgrades in case that the boilerplate has to change, the integrators will have to move the policy add-on to the new boilerplate.
Proposal & Implementation
The configuration has been kept in Cookieplone for backwards compatibility, but it will be removed in Volto 19. So Volto 19 won't load it anymore.
Deliverables
Volto won't load the project config anymore.
Risks
No risks, this is a new convention, people will have to move the configuration to an add-on which is mostly copy/paste operation and fix the imports.
Participants
Víctor Fernández de Alba
Would documentation of the new way of doing things be a deliverable for this PLIP? I'm not sure whether it is covered elsewhere.
I like this idea and only have one concern here: iirc Volto 19 is supposed to be the default version of Plone 6.2, right? This would cause an important breaking change in upgrading from Plone 6.1 to Plone 6.2. I know that it's not guaranteed that we have no breaking changes in Plone upgrades, but it this worth it?
@pnicolli We issued the deprecation notice already in 18. This has not to be any different than any other breaking change. Mitigating this breaking is following the best practices which we've been advocating since years ago already, and move the config to an add-on is not that difficult. I agree that it would be advisable to have a document that shows how to do it. I can look into that to sum up to this PR.
In addition, one could upgrade to Plone 6.2 and avoid upgrading to 19, although given how easy is to move to an add-on driven development would be not worth what you would be loosing.
All an all, is a breaking, yes. But, I'd say it's much of a burden to leave it there "just because" than issuing the breaking change properly and include it in 19.
@sneridagh Yeah I mean, I don't want to block this at all, don't get me wrong :) I was worried about the possibility of receiving feedback along the lines of "you are breaking something for very little benefit". Just wanted to make sure this concern was raised, but I have given it some thought in the past few days and I am still ok with doing this, keeping things clean is the way to go.