[stanleyphu]

Why

@workos-inc/node 12.0.0 is the first SDK whose feature flag runtime client honors targeting rules that serve false. Earlier versions ignore those rules, so they return true for an excluded user or organization. This package only accepts v9 and v10 as peers, so a Next.js app using getFeatureFlagsRuntimeClient() can't get exclusions right. Customers turning on targeting rules are asking for this.

• The peer range is now ^9.0.0 || ^10.0.0 || ^11.0.0 || ^12.0.0, and the dev dependency moves to ^12.0.0.
• v12 returns User timestamps as Date objects, but the sealed session stores them as ISO strings. Without a change, withAuth().user.createdAt would be typed Date but be a string at runtime. With v12 installed, reading a session from the cookie or the middleware header now turns createdAt, updatedAt and lastSignInAt back into Date objects. With v9 to v11, which type them as strings, sessions are returned unchanged.
• README:
  • Keyless mode now lists v9 through v12.
  • The runtime client example registers an error listener. In v9 to v11, a failed sync with no listener stops all further syncs and can crash the process.
  • It notes that versions before v12 ignore rules that serve false.

Proof

• The Date problem: with v12 installed and before the session.ts change, the existing withAuth test failed because createdAt came back as "2024-01-01T00:00:00.000Z" instead of a Date. It passes after the change.
• New getSessionFromCookie tests:
  • With v12, timestamps come back as Date objects.
  • A null lastSignInAt stays null.
  • With an older SDK version reported, timestamps stay strings.
  • The v12 test fails without the change.
• v10 and v11: I installed @workos-inc/node 10.14.0, then 11.0.0, in place of 12 and ran the whole suite. Each time, only the two tests that assert v12's Date timestamps failed, which is expected because those versions type timestamps as strings. All other 494 tests passed, including keyless mode and feature flags.
• The README's error listener claim: 9.3.1, 10.0.0, 10.14.0 and 11.0.0 all call emit("error") in the poll loop without checking for a listener. On 10.14.0, a first sync that failed with a 500 crashed a plain Node process with an unhandled GenericServerException. With the rejection caught, polling still never resumed, and flags never loaded even though the next poll would have succeeded. With the README's listener, the client retried and loaded flags. v12 checks for a listener first (fix(feature-flags): Keep polling when no error listener is attached workos-node#1728).

Not proven

I haven't run this in a real Next.js app against a WorkOS environment. To check it, run an app with WORKOS_* credentials on @workos-inc/node 12 and confirm:

• After sign-in, withAuth().user.createdAt instanceof Date is true.
• After the access token expires and the middleware refreshes the session, it's still true.
• getFeatureFlagsRuntimeClient() polls /sdk/feature-flags?payload_version=2 and returns false for a user excluded by a rule that serves false.

🤖 Generated with Claude Code

[workos-shipyard]

⚓ Shipyard review suggestion

Suggested team: applied-ai, based on recent contributors to the changed files (@nicknisi, @mitch-fultz).

• Assign @mitch-fultz · 1 assignments in the last 7 days
• Assign @meganspaulding · 4 assignments in the last 7 days
• Assign @ryanfitzgerald-workos · 5 assignments in the last 7 days
• Pick for me · balances recent workload

Links open Shipyard for confirmation. Choosing a reviewer overrides availability; “Pick for me” skips known absences.
Comment /tag <team> for a team or /tag to infer one. Tag the same team again to reroll.

Shipyard Analysis

⏳ Generating analysis...

⚓ Explore the analysis in depth in Shipyard · 🔄 Re-run analysis

[workos-shipyard]

⚓ Review requested from @gjtorikian for team dx, requested by @stanleyphu.

Shipyard Analysis

⏳ Generating analysis...

⚓ Explore the analysis in depth in Shipyard · 🔄 Re-run analysis

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Adds support for @workos-inc/node v11 and v12 while keeping v9 and v10 supported.

• AuthKit supports WorkOS Node SDK versions 9 through 12.
• Session reads return user timestamps in the installed SDK's expected form.

No actionable issues found. Tests were not run; dependencies are not installed.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Cookie[Sealed session cookie] --> Unseal[Unseal session]
  Header[Sealed session header] --> Unseal
  Unseal --> Version{SDK version}
  Version -->|v12| Dates[Restore user dates]
  Version -->|v9 through v11| Unchanged[Keep timestamps unchanged]
  Dates --> Caller[Return session]
  Unchanged --> Caller

Loading

_{Reviews (1) · Last reviewed commit: "feat: support @workos-inc/node v12" · Reviewed by Greptile}