chore: upgrade minimum Node.js runtime to 20.19.0 by cschetan77 · Pull Request #485 · auth0/node-jwks-rsa

cschetan77 · 2026-02-16T11:27:20Z

🛠️ Changes

Bumps supported node runtime to ^20.19.0 || ^22.12.0 || >= 23.0.0
CI changes
- Build and Test Matrix - Matrix includes minimum node versions supported by SDK - 20.19.0, 22.12.0 and 23.
- Github Actions - checkout@v6 | setup-node@v6 across all the actions and workflows.

📋 Motivation

This change is driven by the need to modernize our dependency tree and ensure long-term support for the SDK.

Dependency Modernization & ESM Interoperability
Several critical dependencies, including jose and lru-memoizer, are currently pinned to legacy versions ([email protected] and [email protected]).

The ESM Challenge: Modern versions of these packages (e.g., [email protected]) have transitioned to ESM-only and can't be require() ed directly.

The Solution: Node.js recently introduced stable support for require()-ing synchronous ESM modules (unflagged in v20.19.0, v22.12.0, and v23.0.0). By raising our minimum version to v20.19.0, we can finally upgrade these dependencies while maintaining a CommonJS (CJS) interface for our SDK users without complex build workarounds.

Deprecation of Legacy Runtimes
Node.js 14, 16, and 18 have all reached End-of-Life (EOL).

Continuing support for these versions prevents us from adopting modern security patches and performance improvements available in newer runtime engines.

Removing these legacy runtimes reduces our maintenance overhead and ensures that our users are running the SDK on a secure, supported platform.

⚠️ Breaking Changes

Minimum Node.js Version: Requires Node.js >= 20.19.0.

References

Loading ESM using require

Testing

Unit tests
Standalone SDK API calls
Examples

semgrepcode-auth0 · 2026-02-16T11:29:37Z

package-lock.json

@@ -2127,13 +2311,15 @@
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/express-unless/-/express-unless-1.0.0.tgz",
      "integrity": "sha512-zXSSClWBPfcSYjg0hcQNompkFN/MxQQ53eyrzm9BYgik2ut2I7PxAf2foVqBRMYCwWaZx/aWodi+uk76npdSAw==",
-      "dev": true
+      "dev": true,
+      "license": "MIT"
    },
    "node_modules/express-jwt-v6/node_modules/jsonwebtoken": {


Medium severity vulnerability may affect your project—review required:
Line 2317 lists a dependency (jsonwebtoken) with a known Medium severity vulnerability.

ℹ️ Why this matters

Affected versions of jsonwebtoken are vulnerable to Improper Authentication. Insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC.

References: GHSA, CVE

To resolve this comment:
Check if you are using a poorly implemented key retrieval function and your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function..

If you're affected, upgrade this dependency to at least version 9.0.0 at package-lock.json.

If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

/other only used in specs

semgrepcode-auth0 · 2026-02-16T11:29:38Z

package-lock.json

@@ -2127,13 +2311,15 @@
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/express-unless/-/express-unless-1.0.0.tgz",
      "integrity": "sha512-zXSSClWBPfcSYjg0hcQNompkFN/MxQQ53eyrzm9BYgik2ut2I7PxAf2foVqBRMYCwWaZx/aWodi+uk76npdSAw==",
-      "dev": true
+      "dev": true,
+      "license": "MIT"
    },
    "node_modules/express-jwt-v6/node_modules/jsonwebtoken": {


High severity vulnerability may affect your project—review required:
Line 2317 lists a dependency (jsonwebtoken) with a known High severity vulnerability.

ℹ️ Why this matters

Affected versions of jsonwebtoken are vulnerable to Use Of A Broken Or Risky Cryptographic Algorithm. The library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm.

References: GHSA, CVE

To resolve this comment:
Check if you are using a legacy, insecure key type with a supported algorithm; for example, DSA keys could be used with the RS256 algorithm.

If you're affected, upgrade this dependency to at least version 9.0.0 at package-lock.json.

If you're not affected, comment /fp we don't use this [condition]

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

/other only used in specs

frederikprijck · 2026-02-20T07:39:06Z

.github/workflows/matrix.json

+    { "node": "23.0.0" },
+    { "node": "22.12.0" },
+    { "node": "20.19.0" }


Would this always run with these specific versions? Shouldnt we use the latest of all ?

Also, I would recommend include 24 in the matrix, and not 23.

Yes, the gh actions should always run against these specific versions.
I was thinking of keeping just one (latest of all).
But then, the build matrix was already configured and testing for 14, 16 and 18. So, I thought, there does not seem to be any harm to test against minimum node versions that we kept in package.json.

Also, I would recommend include 24 in the matrix, and not 23.

Yes, that makes sense, will update it.

Why should it run against those versions specifically, and not the latest of 20, the latest of 22 and the latest of 24?

Yes, I agree, it should run against latest of 20, 22 and 24.
Reason, I kept them this specific, I was in bit of a doubt with setup-node behavior, if I mention say 20.x, whether it installs the latest ver.
But let me confirm and update these versions to use their latest.

nandan-bhat · 2026-02-25T07:13:49Z

package.json

  "types": "index.d.ts",
  "engines": {
-    "node": ">=14"
+    "node": "^20.19.0 || ^22.12.0 || >= 23.0.0"


Should we document this as a breaking change ?
We documented earlier like this https://github.com/auth0/node-jwks-rsa/blob/master/CHANGELOG.md?plain=1#L57

Yes, this is a breaking change and should be added to changelog.
Thinking of adding it while raising Release 4.0.0 PR

You can add it in the PR description for now.

nandan-bhat · 2026-02-25T07:16:07Z

.github/workflows/test.yml


      # only upload coverage on one node version
-      - if: matrix.node == 18
+      - if: matrix.node == 20


We have ^24.0.0, ^22.12.0, ^20.19.0 in https://github.com/auth0/node-jwks-rsa/blob/e7385b9112f50bf90a5715b12c7f57e1f4e42727/.github/workflows/matrix.json.

Does this condition ever pass if: matrix.node == 20 ?

Thanks for pointing it out, missed to update the condition in previous commit.
Updated, the step now runs for `^20.x.x^

upgrade node@20, regenrate lock, workflows/v6

37a38cc

cschetan77 requested a review from a team as a code owner February 16, 2026 11:27

semgrepcode-auth0 bot reviewed Feb 16, 2026

View reviewed changes

cschetan77 changed the title ~~feat: Upgrade to nodejs@20 and jose@6~~ feat: Upgrade to nodejs@20 Feb 16, 2026

semgrepcode-auth0 bot reviewed Feb 16, 2026

View reviewed changes

cschetan77 changed the title ~~feat: Upgrade to nodejs@20~~ feat: Upgrade supported node runtime to v20+ Feb 16, 2026

update workflow/build matrix

408d8f3

cschetan77 mentioned this pull request Feb 18, 2026

feat: upgrade jose dependency to v6 #486

Merged

cschetan77 changed the title ~~feat: Upgrade supported node runtime to v20+~~ chore: upgrade minimum Node.js runtime to 20.19.0 Feb 18, 2026

frederikprijck reviewed Feb 20, 2026

View reviewed changes

Update build matrix to use latest of node vers

e7385b9

nandan-bhat reviewed Feb 25, 2026

View reviewed changes

update codeconv action to match ^20

20e87b6

nandan-bhat approved these changes Feb 25, 2026

View reviewed changes

cschetan77 merged commit 70983b2 into master Feb 25, 2026
12 checks passed

cschetan77 deleted the feat/node-20 branch February 25, 2026 08:57

This was referenced Feb 25, 2026

chore: update lru-memoizer to v3 #476

Merged

Release v4.0.0 #490

Merged

Conversation

cschetan77 commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🛠️ Changes

📋 Motivation

⚠️ Breaking Changes

References

Testing

Uh oh!

semgrepcode-auth0 bot Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

cschetan77 Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

semgrepcode-auth0 bot Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

cschetan77 Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frederikprijck Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cschetan77 commented Feb 16, 2026 •

edited

Loading

cschetan77 Feb 25, 2026 •

edited

Loading

cschetan77 Feb 25, 2026 •

edited

Loading

frederikprijck Feb 20, 2026 •

edited

Loading