This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Run yarn build
yarn run v1.22.22
error @commitlint/root@1.0.0: The engine "node" is incompatible with this module. Expected version ">=v20". Got "18.19.1"
error Commands cannot run with an incompatible environment.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 1.

@knocte looks like Ubuntu 24.04 is shipping with node v18?
We usually drop a node version if it's out of maintenance.

But other releases are not LTS.
What's the best way to deal with this?

Also tagging @kaiehrhardt @jeohist , sorry!
Happy for feedback.

What features are we going to use which are only available in Node 20+?

What features are we going to use which are only available in Node 20+?

Propably none? We used to switch versions when they ran out of maintenance. Should we not? Can also just leaves this as is for now.

Personally I'd prefer supporting non LTS versions if there are no efforts required and no new great features we're going to use whenever possible for larger compatibility.

Fair enough 👍

Personally I'd prefer supporting non LTS versions

Let's not be ambiguous. You don't mean "let's support non LTS versions", you mean "let's not support LTS versions".

Let's not be ambiguous. You don't mean "let's support non LTS versions", you mean "let's not support LTS versions".

Your words are as always intense which I don't understand why. >=v18 includes >=v20 what means LTS versions are surely supported. Maybe I mean "let's not only support LTS versions".

Sound like we agree with keeping v18 as long as if there's no good reason to upgrade.
I'll leave this as a draft PR.

I believe there is a misunderstanding here. When you mention "LTS" you're probably referring to NodeJS versions. However, I myself was referring to Ubuntu versions.

Sorry, my last 2 replies in this github issue were not really appropiate because I had only read a few comments, but not the ping from @escapedcat . Now I'll reply:

@knocte looks like Ubuntu 24.04 is shipping with node v18?

I have no idea what's Ubuntu's roadmap with regards to upgrading NodeJS in UbuntuLTS versions, but the idea of including the CI job titled "NodeJS installed from stock Ubuntu-LTS packages (not external sources)" was precisely to avoid phasing out NodeJS versions that are still supported in the last LTS version of Ubuntu.

I understand why watching what NodeJS versions are falling out of support is important, but there are people that care more about software releases falling out of support at a distro level (e.g. people that just need NodeJS because it is a dependency of other software they use, but they don't care or know anything about NodeJS). I think commitlint could drop support of old NodeJS versions only when a new Ubuntu LTS version comes out that supports newer NodeJS versions, because if there were security bugs/issues present in the NodeJS version that the last Ubuntu LTS ships, I'm very certain that Canonical would put some effort into backporting the bugfixes or upgrading the NodeJS version altogether.

@knocte yup, unerdstood. Thanks for your feedback.
As @JounQin already pointed out, we do not need any new features from nodejs currently.
So we wait for now. I'll just leave this as a draft.

Short update here:
Looks like v18 still is being updated but already has issues.
@knocte do you know when Ubuntu LTS might support a newer nodejs version?

LTS distros only receive bug fixes, not new features, therefore I doubt that Ubuntu 24.04LTS will upgrade to a new version. But if we want to upgrade to new NodeJS we can simply wait for next LTS (26.04). What's the rush to upgrade? What are the features from v20 that commitlint needs?

LTS distros only receive bug fixes, not new features, therefore I doubt that Ubuntu 24.04LTS will upgrade to a new version.

What's the rush to upgrade? What are the features from v20 that commitlint needs?

No rush. Just checking on the LTS status. And looking at the currently looking issues of v18 I'm a bit worried there might be more coming up in the future and eventually fixing older versions will stop, see i.e. v16

But if we want to upgrade to new NodeJS we can simply wait for next LTS (26.04).

For now we can wait for next LTS

And looking at the currently looking issues of v18

But AFAIU they will keep updating v18 (to v18.x.y.z where x.y.z will contain some fixes for vulnerabilities). And Ubuntu24.04 will pick those up. And if Canonical finds that some security vulnerabilities are fixed in v20 and not v18, their engineers will probably backport the fixes themselves. That's the point of a distro, you trust their team alone so that you don't have to trust dozen of other smaller ISVs.

Closing this. Looks like the new Ubuntu LTS will ship with node 22

Ubuntu 26.04 LTS (Resolute Raccoon)

• Release Date: April 23, 2026 (source (https://discourse.ubuntu.com/t/resolute-raccoon-release-schedule/47198))
• Node.js Version: 22.22.0 (source (https://packages.ubuntu.com/resolute/nodejs))
• Codename: Resolute Raccoon

Related to: #4554 (comment)

Coming back to this from the further comments in #4554.

I went back and looked at how Mario (the original author) handled Node version upgrades. He had this in the readme:

"conventional-changelog-lint supports the active Node.js LTS version and higher: >= 4"

This was accidentally lost during the big package rename in July 2017 and never carried over to the new docs. But the practice itself continued — both Mario and I consistently dropped Node versions ~1-2 months after their official EOL, following the Node.js LTS schedule. That changed when we adopted the Ubuntu LTS approach.

No user has ever complained about either practice.

After Ubuntu 26.04 releases (April 23), my plan is to bump the minimum to Node 22 and go back to following the Node.js LTS schedule going forward. If anyone has concerns with that approach, let's discuss before then. Either way, I'll document the policy properly this time so we have a clear reference for future discussions.

No user has ever complained about either practice.

Wrong, I complained about not being compatible with UbuntuLTS's NodeJS version, by the time 24.04 had not been released yet. What's the point of stopping the support of older NodeJS versions if commitlint is not adopting new features from the newer NodeJS versions? At this moment, the only pressing aspect about upgrading is just the dependencies of commitlint trying to dictate forced upgrades, not real features.

my plan is to bump the minimum to Node 22 and go back to following the Node.js LTS schedule going forward.

Could you at least create a stable branch before doing this bump? This way bugfixes can still be backported to this branch, which would still support the "legacy" version of NodeJS from last UbunutLTS version. And then upgrades and removal of compatibility with older versions can happily go into the main/master branch.

PS: On the topic of upgrading for the sake of upgrading, we could also talk about the recent supply-chain attacks that happened with axios ;)

I second @knocte

Thought so. I won't be creating a stable branch — I maintain this project solo, and committing to backporting bugfixes across two release lines isn't realistic for me. commitlint is a dev-time tool for checking commit messages — it's not a runtime dependency that other projects ship against — so the impact of bumping the Node floor is small: anyone stuck on older Node can pin to the last v20.x release and keep using it indefinitely.

(used Claude to create this reply)

Dropping support for EOL Node.js means that you are dropping support for projects older than 2.5 years old. v18 is 4-years old.

Thought so. I won't be creating a stable branch — I maintain this project solo, and committing to backporting bugfixes across two release lines isn't realistic for me.

Ya, it's be a bit too much.

commitlint is a dev-time tool for checking commit messages — it's not a runtime dependency that other projects ship against

Yes. But we get security reports on all dependencies.

anyone stuck on older Node can pin to the last v20.x release and keep using it indefinitely.

I found out of the upgrade while fixing GHSA-v39h-62p7-jpjc (through ajv, through conventional-changelog).

Why limit the users of your tool when there no direct benefits to it?

Dropping support for EOL Node.js means that you are dropping support for projects older than 2.5 years old. v18 is 4-years old.

Age isn't the criterion — if Node moves on (for good reasons, I trust), we move on. The benefits I care about are being able to update deps and use newer Node features.

But we get security reports on all dependencies.

Fair, and I get the frustration. But the answer for that is on the consumer side: either upgrade your project's Node, or pin commitlint to the last v20-compatible release. I won't maintain a parallel release line for EOL Node — that's the cost a solo maintainer can't carry.

Why limit the users of your tool when there no direct benefits to it?

I don't see it as limiting — you're free to use whichever commitlint version matches your Node. Majority of users have never complained. If anything, more people have complained about not moving on quickly enough than about dropping older versions. If I'm inconveniencing ~5 users, I'll take that.

I second @knocte

I won't be creating a stable branch

Mind you, I only requested the creation of a stable branch if/when commitlint required a version of Node that the last LTS version of Ubuntu didn't have by default. Right now, this is not the case, because 26.04LTS was recently released, that brings Node 22.x; so I'm happy (for now).

I'm ok with you not being happy :P

I won't maintain a parallel release line for EOL Node — that's the cost a solo maintainer can't carry.

FTR I wouldn't mind working on backporting fixes myself to a hypothetical stable branch, if it was decided to be created in the future.

Thanks! Good to know, let's see what the future brings