Target of the RFC: Change #5 to set our Node version to the currently active LTS.
The argumentation in #1 had its point in unifying the Node version, making it easier to maintain apps.
But by using the "security maintained LTS version" we can not use new features in development and especially can not use browser supported API without polyfilling. In general we use Node.JS not for runtime but only for development. We target only browsers for runtime.
The proposal would be to change our Node version yearly (currently every October) to the current active LTS version, which is in the moment of writing Node 22.
Pro:
Having access to new features during development
API closer to latest ES
Potential improvements like speed
Con:
Update Node versions every 12 month instead of 30 months
The past has shown that we are not even fully using the security maintained version, as we switched to 20 before 18 was EOL in April this year.
The argumentation in #1 had its point in unifying the Node version, making it easier to maintain apps. But by using the "security maintained LTS version" we can not use new features in development and especially can not use browser supported API without polyfilling. In general we use Node.JS not for runtime but only for development. We target only browsers for runtime.
The proposal would be to change our Node version yearly (currently every October) to the current active LTS version, which is in the moment of writing Node 22.
Pro:
Con:
The past has shown that we are not even fully using the security maintained version, as we switched to 20 before 18 was EOL in April this year.