Update frontend_addon template to support Volto 19

[davisagli]

Fixes #206 ... or at least a start

So far I only added vitest, based on #207.

First I started trying to add subtemplates for volto 18 and volto 19 which could override specific files. But that quickly became a multiplicative problem because we needed different Makefiles and package.json for volto 18 and volto 19, but also different Makefiles for the standalone frontend_addon template vs when it's used in a project. So I abandoned that approach and switched to more targeted conditionals instead.

To do:

• vitest
• pnpm 10
• Update cookieplone to allow Node 24 - Add support for Node 24 cookieplone#114
• update deps (cypress, storybook, etc) and their configs
• Update Volto cookieplone test to test with Node 24 - Run cookieplone acceptance test with Node 24 volto#7537

If you want my help, I need an example where you can point out all the specific changes that are needed.

[wesleybl]

@davisagli Can't we have vitest on Volto 18? Maybe a question to choose the test famework?

[wesleybl]

pnpm 10

See: #259

[davisagli]

Can't we have vitest on Volto 18? Maybe a question to choose the test famework?

@wesleybl I'm not interested in supporting two different test frameworks for a single major version of Volto. If there are multiple ways to do things, it's harder to document and harder to tell new folks what to do.

If you really need it and know what you're doing, you can already (with this PR) build a frontend addon for Volto 18 using vitest, like this: COOKIEPLONE_REPOSITORY=path/to/cookieplone-templates uvx cookieplone frontend_addon __test_framework=vitest

[sneridagh]

@davisagli @wesleybl I did a bit of research and asked the machine too, and I got this answer:

Package	Needed for typical Volto dev/build?	Why / when it’s needed
@parcel/watcher	No (optional)	Native file-watcher some tools prefer for faster rebuilds. Volto uses Webpack’s own watcher (via chokidar), so this is safe to skip.
@tailwindcss/oxide	No (unless you’re on Tailwind v4)	Oxide is Tailwind v4’s Rust engine. Only needed if your project uses Tailwind v4; classic Volto doesn’t.
core-js / core-js-pure	Maybe (JS-only)	Polyfills pulled in by Babel (preset-env) if configured with useBuiltIns. No native code here, so not a binary concern.
es5-ext	Maybe (JS-only)	A set of ES shims/utilities used by some dependencies. Pure JS, no native build.
esbuild	No for core Volto; Maybe for tooling	Volto uses Webpack. esbuild appears if you use Storybook with an esbuild/Vite builder or plugins like esbuild-loader.
full-icu	No (optional)	Provides full ICU data for Node’s Intl features. Only needed if your Node runtime (SSR, scripts) requires full locale support.
unrs-resolver	No (dev-only/optional)	Rust-accelerated module resolver used by things like eslint-plugin-import-x. Optional speed-up, not required for build/run.
why-is-node-running (“why”)	No (dev-only)	Debugging helper to find open handles when Node won’t exit. Only used manually.

I don't like to have to micromanage this, but I see the point. However, I'd add these at least to the list:

core-js / core-js-pure / es5-ext (polyfills and shims, the build might be using them)
esbuild (used by storybook in @plone/components)
@tailwindcss/oxide (used by @plone/components)
full-icu (I'm sure we are using it)
unrs-resolver (used by ESlint in dev)
why (a tool we pushed for back in the day that is util for dev)

I will update the PR if you all agree.

[wesleybl]

@sneridagh Of course. If the scripts for these packages are necessary, we can add them. By default, pnpm 10 doesn't run the scripts unless explicitly specified. I tried to keep the default. Since the tests passed, this was an indication that we didn't need them. But if we do, we can add them. What I don't think we should do is add them unnecessarily.

[wesleybl]

@davisagli Why didn't you want to keep ignoredBuiltDependencies? It's there so that pnpm doesn't keep warning you that it's ignoring these packages.

[wesleybl]

@davisagli @sneridagh Another thing we need to do is add support for Node.js 24 in Volto 19.

I tried running the Volto tests from cookieplone with Node 24:

https://github.com/plone/volto/blob/main/.github/workflows/cookieplone.yml#L16

but I got an error that the Node version wasn't supported. I think the SUPPORTED_NODE_VERSIONS variable controls this:

https://github.com/search?q=repo%3Aplone%2Fcookieplone-templates%20SUPPORTED_NODE_VERSIONS&type=code

[wesleybl]

Another thing is that we will have to have a test matrix for Volto 18 and another for Volto 19. Maybe the make generate command should consider both versions.

[davisagli]

@davisagli Why didn't you want to keep ignoredBuiltDependencies? It's there so that pnpm doesn't keep warning you that it's ignoring these packages.

It could be useful information if the developer of a Volto project wants to use those packages directly, even if Volto itself does not.

Another thing we need to do is add support for Node.js 24 in Volto 19.

Good point, I added it to the to-do list in the PR description.

Another thing is that we will have to have a test matrix for Volto 18 and another for Volto 19. Maybe the make generate command should consider both versions.

Yeah, that would be ideal.

[wesleybl]

It could be useful information if the developer of a Volto project wants to use those packages directly, even if Volto itself does not.

I find these warnings strange. It seems like something is wrong. But that's okay with me.

Good point, I added it to the to-do list in the PR description.

Would it also be necessary to add a task to update Volto tests with version 24? Or will you remember that?

[davisagli]

I'd add these at least to the list:

Let's check what the lifecycle scripts are actually doing...

core-js / core-js-pure

These just have a postinstall script which prints an ad banner (https://github.com/zloirock/core-js/blob/master/packages/core-js/postinstall.js).

es5-ext (polyfills and shims, the build might be using them)

This one has a postinstall script which prints a call for peace when installed in a Russian timezone (https://github.com/medikoo/es5-ext/blob/main/_postinstall.js).

esbuild (used by storybook in @plone/components)

This one looks necessary, to build a Go binary.

@tailwindcss/oxide (used by @plone/components)

This has a postbuild script but nothing on install.

full-icu (I'm sure we are using it)

This has a postinstall script which is the entire point of the package (to download locales).

unrs-resolver (used by ESlint in dev)

This has a postinstall script which looks necessary.

why (a tool we pushed for back in the day that is util for dev)

This has a postinstall script which just prints a line about how to use it.

Actually, do we still need this? pnpm has its own why command (https://pnpm.io/cli/why)

[davisagli]

update deps (cypress, storybook, etc) and their configs

@sneridagh where can we find an example of these changes?

[wesleybl]

update deps (cypress, storybook, etc) and their configs

@davisagli I would try using Cypress 15 on the Volto 19. But we would have to do it on the Volto first. And I believe it would be transparent here.

[sneridagh]

@davisagli I will look into Storybook ones. I already did for Seven.

[sneridagh]

@davisagli @wesleybl I added plone/volto#7562. I can think in a couple of use cases where it will come in handy. It needs this one to be green though.

There's also: plone/volto#7538 When it's merged, I think we can go with this one.

Also: after spending some hours in trying to update Storybook to 9, I abandoned. It's few things that it would give us in exchange for the lots of effort that it has to be done to make it work. Reason? They are focusing in a very sleek Vite build, so they slimmed down all deps and build deps to the minimum, so if you really need them, you have to provide them yourself... anyways, I think it's not worth the effort, and the things that Storybook 8 gives you are lots and we underuse them anyways...

[wesleybl]

@sneridagh I think after adding a test matrix for the alpha version, we can merge this one here.

[wesleybl]

We also need to add the packages to onlyBuiltDependencies.

[sneridagh]

I think now it's ready. @davisagli @wesleybl take a final look and let's make it happen.

The tests are failing because https://json.schemastore.org/hatch.json is down...

[wesleybl]

The tests are failing because https://json.schemastore.org/hatch.json is down...

@ericof @sneridagh see: collective/pytest-jsonschema#8

[ericof]

@sneridagh, @davisagli, @wesleybl: There's a 1.0,0 release of pytest-jsonschema.

[sneridagh]

@davisagli @wesleybl I'd say let's merge it, right? or there is something else left?

[davisagli]

LGTM. (Sorry, I'm hosting family this weekend and not paying much attention.)

[wesleybl]

@sneridagh I was thinking of creating an matrix in the existing job, instead of creating a new one. That way we'd avoid code duplication. Maybe I can try that later.