Replies: 2 comments
-
|
Absolutely. As a fellow library maintainer as well as a consumer of this library and someone often utilizing older nodejs versions, supporting versions that have significantly passed "End Of Life" is incredibly challenging. I don't wish that on anyone. Long tail node support always exists with those previous versions. It's the risk of using old versions — no new features. In these discussions it helps to focus on exactly which version is often a challenge, for instance, I know for some of our libraries, nodejs 18 might be doable but nodejs 16 is way passed due. Asking for "old LTS versions" is vague, so I might recommend if there is a specific scenario, instead it would make sense to specifically specify which end of life version and which exact feature is necessary, it might be possible to back port that. But from my perspective as a maintainer, upgrade or fork, there is no value in trying to back port functionality that requires not only polyfills but also different versions of development libraries to even build the output. |
Beta Was this translation helpful? Give feedback.
-
No, there's no formally defined roadmap. Historically I've been referring to Node's Release Schedule to help inform which versions of Node to support: https://nodejs.org/en/about/previous-releases#release-schedule "The three latest LTS releases" has been how I've chosen what versions of Node to support. A Node LTS release finally going EOL has been easy for me to say "okay, I can put this in my rearview mirror." It was really the availability of Of course, having spent a lot of time personally and in industry building things for the web, I totally understand your frustration that this project's minimum Node version is v20 if you're not yet able to upgrade Node versions. Especially because of how hard it can be to justify to others why it's worthwhile to invest in the codebase refactor required when upgrading Node. Keeping up with LTS releases is arguably good for application security, but I know it can be hard to convince others of this too. I guess if I can offer any consolation it's that there's not been any new Node features since Node v20 that've had me jonesing to drop support for v20. It'll likely remain the minimum-supported Node version for now. Is SimpleWebAuthn important enough for your project that you can use "because SimpleWebAuthn needs at least Node v20" to make the case to others that it's time to upgrade your Node runtime version? 😅 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is there a roadmap or technical constraint that prevents supporting older Node.js LTS versions?
The current reliance on
webcryptosignificantly narrows compatibility, while the traditional crypto module is available and stable across a much broader range of node versions. For projects targeting enterprise or commercial adoption, long-tail node support is often a hard requirement due to slower upgrade cycles and compliance constraints.Beta Was this translation helpful? Give feedback.
All reactions