Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New setup #109

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open

New setup #109

wants to merge 20 commits into from

Conversation

sneridagh
Copy link
Member

@sneridagh sneridagh commented Jul 4, 2024

I promise that once you try the new setup, it's no turning back, and everything else seems so wrong and outdated.

Give it a try!

@pnicolli maybe it's better to merge first the PRs that you told me you have ongoing. Up to you. However, I saw that we have no tests whatsoever, we can fix this too. There are a couple of concerning ESlint failures that I commented out for now, but it would be great to fix it.

Copy link
Member

@pnicolli pnicolli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it's ok to remove all the files in old since we are targeting this at a 4.x release, maybe with at least an alpha to test early on

README.md Outdated
Comment on lines 199 to 207
### Volto 18 and later

Add `volto-form-block` to your add-on `package.json`:

```json
"dependencies": {
"volto-form-block": "*"
}
```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify: with volto 18 we still need to add the add-on name to the addons array and to run pnpm add volto-form-block or pnpm install, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the add-on needs to be declared too as usual, the recommended way is to do that in your policy package (inside packages folder.

volto.config.js must have an entry point though, normally pointing to the inner package in packages.

Makefile Outdated
.PHONY: backend-docker-start
backend-docker-start: ## Starts a Docker-based backend for development
@echo "$(GREEN)==> Start Docker-based Plone Backend$(RESET)"
docker run -it --rm --name=backend -p 8080:8080 -e SITE=Plone $(DOCKER_IMAGE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also needs the backend add-on. iirc with -e ADDONS="collective.volto.formsupport"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pnicolli let's move the addon in here too, so we have the complete add-on parts in the same repo.

package.json Outdated Show resolved Hide resolved
@mamico
Copy link
Contributor

mamico commented Jul 8, 2024

@sneridagh I like the frontend/backend "monorepo" idea for volto addons, I had also written some time ago at https://community.plone.org/t/monorepo-for-plone-volto-addons/18688 to seek opinions on it

Some thoughts (I know you are probably in the middle of the work):
I assume we will have to change the version to something like 4.x, right?
Is it possible to continue using plone/meta or do you think we need to create something similar or ..?
How about having the same version and sharing the changelog between the backend and frontend?

@sneridagh
Copy link
Member Author

@mamico trying for the first time here.
The whole idea of the new cookieplone setups is that there is no difference between having:

  • a project of a Plone site that it will be deployed, eventually
    • each backend and frontend having a "policy" add-on that describe the project
  • an add-on, with potentially having a backend and a frontend part
    • where each add-on will be published and released packages

Unified testing e2e, unified compatible releases. Follow semantic versioning in both.

Since this will be the first one, we need to polish the idea, though:

  • Should we keep an unified changelog? (I'd say yes, but keeping the particular ones)
  • Can we use plone/meta? This is a question that we are currently discussing in the community. To my understanding, this is going to be impossible.
  • Unified README? I would do so, yes. With info of the add-ons and their requirements "as a whole".

With the version 4 you mean, when we are ready, we will issue major versions? Yeah, we must, I'd say, if they are really breaking. We will need to deprecate the old repo too and point to here.

LICENSE Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably also have a license file in the repo root, or even just a single one. I checked a couple repos and they use the two approaches (everywhere / only root):

https://github.com/adobe/react-spectrum
https://github.com/vercel/next.js

version.txt Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this for? Just curious, I didn't go deep into cookieplone yet

@mamico
Copy link
Contributor

mamico commented Jul 9, 2024

This is another lighter approach, which I like, https://github.com/wagtail/wagtail they put mostly in the root of the repo (both setup.py and package.json).

@sneridagh
Copy link
Member Author

@ericof thanks a lot!!!!

@sneridagh
Copy link
Member Author

@mamico @cekk @pnicolli this is ready now. We've implemented a new approach in the backend, different from the plone/meta approach, which only works in backend-only Python packages. The idea is to push this approach instead of the plone/meta one. This might need time, but we need a first implementation and experimentation with it. So this way will make it to cookieplone and the new generators.

Also, this will be the first full-fledged hybrid add-on so it will allow us to have lots of feedback for making the above a reality.

TBH, I'd merge it asap, and deprecate the old backend repo, if possible. What do you think?

Let's talk about it during today's meeting.

@mamico
Copy link
Contributor

mamico commented Jul 16, 2024

@mamico @cekk @pnicolli this is ready now. We've implemented a new approach in the backend, ...

@sneridagh Thanks for the awesome work, I will check it out ASAP, definitely before the end of this week.

@sneridagh
Copy link
Member Author

@mamico @pnicolli I think the things that we should settle still are:

  • Unified CHANGELOG.md?
  • Unified README?
  • Unified version?

What do you think? My take would be to unify the README, but keep the CHANGELOG separated, and do the same for the version, so each add-on has their own life. This will force us to maintain a table with the compatibilities, but as long as we stick to semantic versioning in both sides, it shouldn't be hard.

@mamico
Copy link
Contributor

mamico commented Jul 17, 2024

@mamico @pnicolli I think the things that we should settle still are:

* Unified CHANGELOG.md?

* Unified README?

* Unified version?

What do you think? My take would be to unify the README, but keep the CHANGELOG separated, and do the same for the version, so each add-on has their own life. This will force us to maintain a table with the compatibilities, but as long as we stick to semantic versioning in both sides, it shouldn't be hard.

I see two options:

the first is to have a single version for backend and frontend:
PROS: no possible misalignment errors, because backend and frontend go in complete sync; simple repo tags (4.1.2, 4.1.3, ...)
CONS: need for releases without any change in either component, because of a release of the other one

the second is to be very strict with semanticversion: given independent versions X.Y.Z. But any X.Y version of the frontend must work with any X.Y version of the backend and vice versa, (e.g. 4.1.9 of the frontend must work with 4.1.2 of the backend). Thus a breaking change that requires simultaneous backend and frontend changes must require at least a Y increment.
PROS: independence of releases between backend and frontend.
CONS: need for discipline on semanticversion, more “complicated” repo tags, I imagine something like frontend-4.1.2, backend-4.1.9, ...

I don't have a very strong opinion on the choice ... but on the balance of pros/cons at the moment the former would win

IMO the CHANGELOG follows the version policy.

frontend/package.json Show resolved Hide resolved
frontend/pnpm-lock.yaml Show resolved Hide resolved
@mamico mamico self-requested a review July 19, 2024 11:46
@mamico
Copy link
Contributor

mamico commented Jul 19, 2024

@sneridagh @pnicolli there is a problemi to discuss: zc.buildout

In my tests adding:

develop +=
   src/volto-form-block/backend/

buildout does not use the package, probably due to lack of setup.py (buildout/buildout#645)

I have not tested with the product egg/wheel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants