Monorepo for plone/volto addons?

I am not an expert on monorepo, but I was thinking if this was or not a model to adopt for some Plone addons.

I was thinking where we currently have two repos: one with JS code for Volto and a second with python code for Plone, but both need to coexist to solve a common use case (e.g. GitHub - collective/volto-form-block: Volto addon for a customizable form block and GitHub - collective/collective.volto.formsupport: Enable support for customizable forms in Volto).

Thoughts?

Mauro.

I was also thinking it would be nice to have both the Python and Node packages for an addon in one repository, but I didn't find time to try it yet. @ericof I forget, did you experiment with this already?

Both of a combo, backend and frontend add-on, living in one repo is appealing.

A straight forward way is granting each one a src directory (I did it with 'src' for the Python code, 'voltosrc' for the Volto code)
As a 'src' directory is expected also for a Node package, this unusualness can be treated with an amendment in package.json entry like

"main": "voltosrc/index.js",

I remember that I needed to add a custom i18n.js to the add-on to collect the translatables, which is only customized with the path of the Volto code living in voltosrc.

I would call the directories backend and frontend, for similarity with how we structure Volto projects. And keep each one structured the same way that it would be if it was a standalone package. package.json can go inside frontend, so it doesn't need any special "main" entry.

But, this is just speculation, and I haven't tried it to see what challenges remain.

1 Like

Enforcing a monorepo structure at addon level makes it more difficult to integrate it into other projects. Not impossible, but difficult.

For example, sometimes the addons are incomplete or have bugs that need to be fixed. Maybe we develop new functionality that relies on something else from my project. Now, I'd have to instruct both mxdev and mrs.developer that I need to checkout a particular path from an addon repository. As extra, it may not even be possible, with the existing infrastructure, to make a single clone of that addon repository, to be shared between backend and frontend.

I would call it combined-repo, since my association with monorepo is more like all-of-Plone-in-one.

If done for one combined addon, I agree with @davisagli, two directories for each, backend and frontend, in both the expected structure for Python or Node following the domains best practice. An explaining README on top level and for ease of development a Makefile to build/start all together.

Latter would be pro monorepo for an addon. Con is, if its something working fine w/o Volto in ClassicUI there is overhead. Also con: Another way to structure a package: adds complexity.

Overall I am +/-0.