Formalize and implement a clear Node.js version support policy

[thomvaill]

Context

I (the maintainer) was absent from the project for a long time (see #108 (comment)) so now the project runs only up to Node.js v16, which is not supported anymore since September 2023.
Also, as @jean-francoismougnot mentioned in #108 (reply in thread): Github Actions dropped support of Node 16

There were also some Issues and PR created earlier related to this topic:

• fix: workaround for ERR_OSSL_EVP_UNSUPPORTED build issue #114
• Nodejs 21 doesnt' work #117
• log4brains build broken on node 14.21.3 #106
• Log4brains is broken on Node v18.x #85

Action plan

To make a fresh start, here is a proposal of action plan.
This issue can be considered as an epic; feel free to raise a PR for each item.

• test and merge fix: workaround for ERR_OSSL_EVP_UNSUPPORTED build issue #114 to support Node.js v18 -> @thomvaill
• fix the CI
• write a formalized Node.js version support policy in README.md and CONTRIBUTING.md: I propose to officially support the "active" and "maintenance" LTS versions (see https://nodejs.org/en/about/previous-releases), and to support in a best effort mode the "current" version
• test and make log4brains work on Node v22, and if possible v23 (but best effort)
• optional: automatize the creation of an issue when a new LTS version is available so we don't forget to support it

[Potherca]

Regarding the version support policy and NodeJS version tracking (for possible automation), the nodejs/Release repo contains a JSON that describes releases.

As the CI already uses a matrix to run different NodeJS versions, we could add unstable versions but allow_failures, to get an idea of incoming breakage without actually breaking the build.

[apankratiev-syberry]

Speaking about dependencies in general.
Maybe you have any plans to introduce dependabot/renovate?
Considering that the project has good tests coverage, you could even enable automerge of minor/path dependencies updates

[Potherca]

I'd be interested in other peoples opinions on this before I speak my mind... There are pros and cons, but I is worth discussing, IMHO.

[thomvaill]

I think it is indeed a good idea, especially for a package that is distributed by an npm install -g.
We already had some issues because of "lax" semver dependencies in the package.json so I already opened this debate a long time ago here: #33
Since using renovate involves pinning all the dependencies to strict versions, it would also solve the issue I mentioned in the discussion.
So yes I would totally be in favor of using this tool.
I you are OK with this, I'll edit this post to this task in the action plan at the end (the first steps are more urgent).
But I'd like to hear your thoughts about this first.

[thomvaill]

Hi all,
I've been progressing well on this issue.

Already merged PRs

Sorry I had to merge them without reviews to be able to progress fast + it was quite hard to debug lerna in the CI so it was easier.

Make Log4brains work on Node 18 and 20:

• Make Log4brains run on Node 18 and 20 #124 : the main one
• fix: lerna publish on Node 18-20 #125 : had the move the workaround somewhere else

CI fixes for the new workflow (#121):

• fix alpha releases #126
• fix alpha releases and docker images #127
• fix lerna --force-publish #128
• fix CI post release jobs #129

PR waiting for reviews

The main topic of this issue:

• NodeJS support policy and CI improvements #130 -> once merged, should automatically create a new Issue for the new Node.js LTS v22 which entered in active state yesterday (as @Potherca suggested)

Thanks!

New related issues created during this development

• Upgrade dependencies to fix CVEs and setup a dependabot/renovate-like solution #131 (as @apankratiev-syberry suggested)
• Upgrade Next.js and to remove the openssl workaround #132
• Replace JamesIves/github-pages-deploy-action by actions/deploy-pages #133

[thomvaill]

Fixed in v1.1.0 😃