Update @clerk/nextjs compatibility: unsupported → partial

[Shorebirdmgmt]

Summary

• Updates @clerk/nextjs status in LIBRARY_SUPPORT from unsupported to partial
• Adds test case for the new partial status
• Fixes existing test to use @auth/nextjs for the unsupported-libraries assertion

Context

Closes #800. @clerk/nextjs was marked as unsupported with "deep Next.js middleware integration not compatible," but runtime testing shows this is overly conservative — Clerk's middleware works through vinext's existing shims.

What was tested

Built and ran a Next.js 16 App Router app with @clerk/nextjs v7.0.12 on vinext 0.0.40. Verified against Clerk's live API:

Feature	Status	Evidence
`clerkMiddleware()`	Works	Middleware runs, authenticates requests, returns correct responses
`auth.protect()`	Works	307 redirect to Clerk handshake for unauthenticated page requests
`frontendApiProxy`	Works	`/__clerk/v1/*` proxies to Clerk API with `x-clerk-trace-id` header
`ClerkProvider`	Works	Sign-in page renders with `clerk.browser.js` and publishable key
`x-clerk-auth-*` headers	Works	`x-clerk-auth-status`, `x-clerk-auth-reason` propagated on responses
Clerk handshake flow	Works	Redirect goes through `/__clerk/` proxy (frontendApiProxy working)

Why it works

Clerk's `clerkMiddleware()` uses standard Next.js middleware patterns that vinext already shims:

• `NextRequest` — vinext's shim provides `cookies`, `nextUrl`, `headers`, `ip`, `geo`
• `NextResponse.next()` — sets `x-middleware-next` header, which vinext processes
• `NextResponse.redirect()` — standard redirect, vinext handles 3xx responses
• `NextResponse.rewrite()` — sets `x-middleware-rewrite` header, vinext processes
• `x-middleware-request-*` headers — Clerk's `decorateRequest()` encodes auth tokens via these headers; vinext's `applyMiddlewareRequestHeaders()` unpacks them
• `x-middleware-override-headers` — Clerk uses this for request header passthrough; vinext's `buildRequestHeadersFromMiddlewareResponse()` handles it
• `NextFetchEvent.waitUntil()` — vinext provides this via its `NextFetchEvent` shim

What's still WIP (why "partial" not "supported")

`auth()` in Server Components and Route Handlers uses `next/headers`'s `headers()` and `cookies()` functions to read the auth state that middleware injected. This path hasn't been verified — it depends on vinext's `next/headers` shim correctly exposing the middleware-decorated request headers.

Test plan

• Existing `check.test.ts` tests pass with updated assertions
• New test verifies `@clerk/nextjs` detected as `partial`
• Runtime verified: build succeeds, server starts, Clerk auth flows work

[james-elicx]

/bigbonk review

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@803

commit: bee8fad

[ask-bonk]

Clean change, LGTM. The status upgrade is well-justified by the runtime evidence in the PR description, and the test updates are correct.

Two minor observations (non-blocking):

1. Test fix is sound. The existing "detects unsupported libraries" test was asserting that all returned items are unsupported. Swapping @clerk/nextjs → @auth/nextjs keeps that assertion valid since @auth/nextjs is still unsupported in LIBRARY_SUPPORT. Good catch.

2. Detail string. The new detail text is informative and actionable — it tells users exactly what works and what's WIP. One thing to consider for a follow-up: once auth() in Server Components is verified (the remaining gap), this should be promoted to supported and the detail updated accordingly.

[ask-bonk]

Review submitted. Here's my assessment:

Approved. This is a clean, well-scoped change:

• check.ts: Updates @clerk/nextjs from unsupported to partial with an accurate detail string that enumerates what works (middleware, auth.protect, ClerkProvider, client hooks) and what's still WIP (auth() in Server Components via next/headers shim).

• check.test.ts: Two changes:

  1. The existing "detects unsupported libraries" test swapped @clerk/nextjs for @auth/nextjs — necessary because the old test asserted all items are unsupported, which would break now that @clerk/nextjs is partial.
  2. Added a new focused test verifying @clerk/nextjs is detected as partial with the expected detail text.

The PR description provides thorough runtime evidence for the status change (tested against Clerk's live API with specific features verified). The "partial" designation is appropriate given the remaining auth() gap in Server Components.

github run