#11577 Doc build fixed for node 22. Build strategy

[offtherailz]

Description

#11577 requires to make MapStore compatible with next versions on nodeJS.
Here in this PR I provide:

• A fix to the doc build that allows build also in NodeJS 22 (for a definitive solution see Find alternative to docma #11610 )
• A strategy of build that tests on many versions, to have a clear idea of compatibility at every build, and the possibility to quickly add/remove versions to test. --> Setup CI with Matrix #11643
• Update to documentation

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

What is the current behavior?

#11577

What is the new behavior?

• Now the build is compatible up to Node 25.x

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

[jna4k]

Hey

It looks great with testing different versions of node.js and java. I was thinking about making a similar suggestion, so its great to see that you got to the same conclusion.

I however think it might be a bit excessive to also test the the Node 25. considering odd version numbers are only supported for 6 months, according to their documentation https://nodejs.org/en/about/previous-releases.

Would it make sense to add a checkbox to the PR, so that the user can select frontend and/or backend. If I make a change to the frontend, it doesn't make sense to run backend test. The idea is to minimize the wait time for user, and lower the runtime spent on github.

Final question, would it make sense to also make a test for windows, right not all test are running on ubuntu.

[offtherailz]

hi @jna4k

Hey

It looks great with testing different versions of node.js and java. I was thinking about making a similar suggestion, so its great to see that you got to the same conclusion.

I however think it might be a bit excessive to also test the the Node 25. considering odd version numbers are only supported for 6 months, according to their documentation https://nodejs.org/en/about/previous-releases.

Yes, I was still testing, thank you for the advice, I removed it.

Would it make sense to add a checkbox to the PR, so that the user can select frontend and/or backend. If I make a change to the frontend, it doesn't make sense to run backend test. The idea is to minimize the wait time for user, and lower the runtime spent on github.

Final question, would it make sense to also make a test for windows, right not all test are running on ubuntu.

I didn't see an option like this on github before. It could be cool. Anyway I see that all things here are done in parallel, so for the moment I don't see any bottleneck in testing everything.

For now our tests take 10 minutes while deploy/publish 4m, and parallelism do not look to influence the build that much.

Here another PR still takes ~ 10 minutes.

Usually PRs are done to front-end, that takes most of the time for doing tests. So I think this improvement is not necessary at the moment.
Do you think the introduction of this multi-version test will make slow-down builds in the future (e.g. because of limits or something)?

[offtherailz]

@tdipisa I kindly ask you to:

• Review the version numbers indicated in documentation
• Remember that we need to change branch protection rules too.

[jna4k]

Ah, I didn't notice they were running in parallel, in that case everything looks good.

[offtherailz]

Hi @tdipisa
I removed the CI stuff to make this PR more atomic and mergiable without side effects.
I created a separate PR for CI changes here #11643 (in draft waiting for this to be merged) in order to unblock this one.