ITADN

Expose `StateSchema` / `interfaces` via a side-effect-free subpath export

#435Opendavidmytton 创建于 2026-06-08
D
davidmyttoncommented
`StateSchema` is re-exported from the package root (`index.js` → `export * from './interfaces.js'`), but the only way to import it drags in the entire server runtime, so it can't be used from a test or any non-server context. I'd like a dedicated subpath export (e.g. `@workos-inc/authkit-nextjs/interfaces`) that exposes the schema and interface types without pulling in `next/cache`/server-only code. ## Background `handleAuth` validates the unsealed `wos-auth-verifier` state against `StateSchema` (`interfaces.ts`): ```ts export const StateSchema = v.object({ nonce: v.string(), customState: v.optional(v.string()), returnPathname: v.optional(v.string()), codeVerifier: v.string(), }); ``` We use the headless flow - `getAuthorizationUrl` + `sealData` into `wos-auth-verifier`, then `handleAuth` on the callback. We stash an app-specific value in `customState`, and we want a test that asserts our sealed state still satisfies the exact schema `handleAuth` will parse, so a future shape change fails loudly in CI rather than silently breaking sign-in at runtime. The `exports` map in `package.json` only defines: ```json "exports": { ".": { "types": "...", "import": "./dist/esm/index.js" }, "./components": { "types": "...", "import": "./dist/esm/components/index.js" } } ``` `StateSchema` is reachable via `.`, but importing it loads the root barrel, which transitively imports `auth.js` - `next/cache` and other server-only modules. In a Vitest/Node environment that fails: ``` Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../node_modules/next/cache' imported from .../@workos-inc/authkit-nextjs/dist/esm/auth.js ``` There's no way to import just the schema/types in isolation, so consumers have to hand-maintain a duplicate of `StateSchema` and keep it in sync with the package version manually.
0 条评论