auth-yes/tasks/complete/2026-0821.03.jul.story.auth-yes.modular-workspace-1855.md

TASK METADATA

• Target Files: auth-yes/deno.json, auth-yes/sdk/deno.json, auth-yes/server/deno.json, auth-yes/ui/deno.json, auth-yes/sdk/gen/*
• Core Objective: Architect the modular Deno workspace structure for the standalone auth-yes repository to ensure @auth-yes/sdk is fully isolated and cleanly exportable.
• Dependencies: None.
• Additional Important Notes:
  • Package naming standard: @auth-yes/sdk, @auth-yes/server, @auth-yes/ui.
  • @auth-yes/sdk must have zero database or server imports and be consumable independently.
  • UI JSX compilation relies on "jsx": "react-jsx" with "jsxImportSource": "jsr:@hono/hono@4/jsx" (pure Hono SSR, zero React dependencies).

---

Architectural Considerations & Risks

• Risks: The primary risk is a circular dependency or importing server-side logic into the SDK, which would break the isolation of the SDK. If the SDK depends on the server, external consumers (like ed-droid) will be forced to download unnecessary and potentially insecure backend dependencies.
• Dependency Decoupling for Contracts: The generated ConnectRPC contracts (auth_pb.ts and auth_connect.ts) currently reside in server/gen/. To ensure the SDK has 100% zero dependencies on ./server, these generated files must be moved into the SDK (e.g., sdk/gen/). This way, consumers of @auth-yes/sdk will have all necessary type definitions and client stubs without needing any server files. The server package can then import these service contracts from the SDK.
• JSX Compiler Standard (Zero React): TypeScript and Deno use "jsx": "react-jsx" as the compiler standard for the modern JSX transform. When paired with "jsxImportSource": "jsr:@hono/hono@4/jsx", TypeScript targets Hono's lightweight native SSR engine without pulling in any React runtime or dependencies.
• Alternatives: We could extract the proto contracts into a separate fourth workspace member (e.g., api-contracts). However, moving them directly into the SDK is simpler and provides exactly what external consumers need in a single package.

Proposed Implementation

Phase 1: Root Workspace Definition

1. Create a root deno.json in auth-yes/ managing workspace members: "./sdk", "./server", "./ui".
2. Configure workspace-wide tasks (lint, fmt, check, test).

Phase 2: SDK Package Isolation

1. Create auth-yes/sdk/deno.json with package name @auth-yes/sdk, version 0.1.0, and export definition ("exports": "./mod.ts").
2. Move the generated ConnectRPC contracts from server/gen/ into sdk/gen/.
3. Update sdk/mod.ts to export client functions and proto types, ensuring zero imports point to ../server or ../ui.

Phase 3: Server and UI Package Configuration

1. Create auth-yes/server/deno.json with package name @auth-yes/server.
2. Update auth-yes/server/main.ts to import service contracts directly from @auth-yes/sdk.
3. Create auth-yes/ui/deno.json with package name @auth-yes/ui, including:

   "compilerOptions": {
     "jsx": "react-jsx",
     "jsxImportSource": "jsr:@hono/hono@4/jsx"
   }
   

4. Verify that the Rust spire_ffi crate is properly referenced by server/ and is not exposed or imported by @auth-yes/sdk.

Phase 4: Workspace Verification & Quality Gates

1. Run deno fmt across all workspace members.
2. Run deno lint to ensure zero import violations.
3. Run deno check sdk/**/*.ts server/**/*.ts ui/**/*.ts to verify clean cross-package type resolutions.
4. Run deno test -A to verify test suite execution.