Replace string-based error matching with structured error detection in middleware

[Copilot]

Addresses review feedback from PR #264 regarding fragile error detection logic in Supabase middleware and missing npm version constraint.

Changes

• Structured error detection: Replace string matching on error messages with checks against error properties (status, statusCode, code). Detects auth errors (401/403 status, INVALID_AUTH/INVALID_JWT/JWT_EXPIRED/PGRST301/PGRST302 codes) vs transient failures.

• Module-scope constants: Move AUTH_STATUS_CODES and AUTH_ERROR_CODES to module scope to avoid allocating new Set objects on every error.

• Type safety: Add StructuredError interface for error shape instead of any type assertion.

• npm version constraint: Add "npm": ">=10" to engines field to match @redocly/cli requirement.

Example

// Before: brittle string matching
const isAuthError = lowerErrorMsg.includes('invalid') || 
                   lowerErrorMsg.includes('expired') || ...

// After: structured property checks
const isAuthError =
  (status !== undefined && AUTH_STATUS_CODES.has(status)) ||
  (errorCode !== undefined && AUTH_ERROR_CODES.has(errorCode));

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR refactors error detection in Supabase middleware to use structured error properties instead of fragile string matching on error messages, addressing technical debt from PR #264. The changes improve reliability and maintainability of auth error handling while also adding an npm version constraint.

Changes:

• Replaced string-based error message parsing with checks against structured error properties (status, statusCode, code)
• Moved auth-related constants to module scope as Sets for performance optimization
• Added npm version constraint (>=10) to match @redocly/cli requirement

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/lib/supabase/middleware.ts	Refactored error detection logic to use structured error properties, added StructuredError interface, moved constants to module scope, enhanced logging with structured error details
package.json	Added npm engine constraint (>=10)
package-lock.json	Updated lockfile to reflect npm engine constraint

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The error detection logic has a potential gap: when both status and errorCode are undefined, errors will be classified as non-auth errors and cookies will be preserved. This could miss legitimate auth errors that don't have structured properties. Consider falling back to checking the error message as a safety net when structured properties are absent, or at minimum logging when this classification path is taken so it can be monitored and debugged.

[Copilot]

The error code list may be incomplete. PGRST301 and PGRST302 are PostgREST-specific error codes, but Supabase Auth errors typically use different codes like "invalid_grant", "token_expired", "session_not_found", etc. Consider verifying the actual error codes returned by @supabase/ssr's getUser() method in the documentation or by testing, and adding any missing auth error codes to ensure proper detection.

Suggested change

	const AUTH_ERROR_CODES = new Set<string>([
	"INVALID_AUTH",
	"INVALID_JWT",
	"JWT_EXPIRED",
	"PGRST301",
	"PGRST302",
	const AUTH_ERROR_CODES = new Set<string>([
	// Legacy / generic auth error codes
	"INVALID_AUTH",
	"INVALID_JWT",
	"JWT_EXPIRED",
	// PostgREST-specific error codes that can surface via Supabase
	"PGRST301",
	"PGRST302",
	// Common Supabase Auth error codes (from auth.getUser, token/session issues, etc.)
	"invalid_grant",
	"token_expired",
	"session_not_found",
	"refresh_token_not_found",
	"invalid_refresh_token",
	"user_not_found",

[Copilot]

The optional chaining with structuredError?.status and structuredError?.statusCode is redundant because structuredError is guaranteed to be defined (it's the result of 'error as StructuredError'). The typeof checks are sufficient for runtime type safety. Consider simplifying to 'typeof structuredError.status === "number"' for cleaner code.

Suggested change

	typeof structuredError?.status === "number"
	? structuredError.status
	: typeof structuredError?.statusCode === "number"
	? structuredError.statusCode
	: undefined;
	const errorCode: string | undefined =
	typeof structuredError?.code === "string" ? structuredError.code : undefined;
	const errorName: string | undefined =
	typeof structuredError?.name === "string" ? structuredError.name : undefined;
	typeof structuredError.status === "number"
	? structuredError.status
	: typeof structuredError.statusCode === "number"
	? structuredError.statusCode
	: undefined;
	const errorCode: string | undefined =
	typeof structuredError.code === "string" ? structuredError.code : undefined;
	const errorName: string | undefined =
	typeof structuredError.name === "string" ? structuredError.name : undefined;