chore: remove unused dependencies across the monorepo

[usehoplite]

Summary

Audited every dependency declared in all 21 workspace package.json manifests against actual usage, and removed only entries with zero references. Evidence per removal was gathered with a module-specifier scanner (import/require/dynamic-import forms, script/CLI usage, tsconfig types arrays) plus manual verification of generated code and config files.

Removed (22 declarations, 8 files)

Manifest	Removed
root package.json	g, vercel, nodemailer, @types/nodemailer
apps/web	@hookform/resolvers, @super/claude-sdk, @super/embeddings-sdk, dot, env, pg, @types/mdx, @types/pg, tsx (+ dead transpilePackages entries in next.config.ts)
apps/supercode-cli/client	@hookform/resolvers
apps/supercode-cli/server	@dodopayments/nextjs, @prisma/driver-adapter-utils, @openrouter/sdk, api, oas, @types/pg
apps/superdesign	nanoid
packages/auth	kysely

Kept despite looking unused (verified legitimately referenced)

• @prisma/client-runtime-utils — Prisma 7's generated client (src/generated/runtime/client.d.ts / client.js) imports it directly.
• eve — imported via eve/connections subpath in server agent code.
• motion — imported via motion/react subpath (animate-ui components).
• @types/express, @types/cors — consumed implicitly by tsc for the server's express/cors imports.
• @tailwindcss/postcss — used as object key in every postcss.config.mjs.
• shadcn — dev tooling backing components.json.
• typescript — the tsc binary used by every typecheck script (scanner only matched the literal name).

Lockfile & validation

• bun.lock regenerated with the project-pinned bun@1.2.21 (the sandbox default 1.3.1 caused unrelated version re-resolution churn, so the pinned version was used for CI parity). The regeneration also dropped a stale apps/video workspace block — that directory is not in the repo, and bun install --frozen-lockfile at HEAD already failed because of it.
• bun install --frozen-lockfile → passes (CI gate).
• bun run typecheck → matches HEAD baseline: web, client, superdesign, api, docs, sdk clean; server and cortex-sdk show only pre-existing errors also present on pristine HEAD.
• bun run lint → matches HEAD (web 180 problems identical pre/post; other apps byte-identical).
• bun test → 215 pass / 4 fail; the same 4 failures reproduce on a pristine HEAD worktree (sandbox env: SMALLEST_API_KEY set, non-TTY readline) — no regressions.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
supercli	Ready	Preview	Sep 3, 2026 6:58am UTC
supercli-client	Ready	Preview	Sep 3, 2026 6:58am UTC
supercli-docs	Ready	Preview	Sep 3, 2026 6:58am UTC

[usehoplite]

CI status: failures are GitHub-side runner provisioning, not this PR

The three CI checks (TypeScript Check, Lint, Test) are failing, but not on code. Evidence:

• Every job completes in ~3s with zero steps ever executing: the GitHub Actions API for these jobs reports runner_id: 0, empty steps: [], and no log content — the runner is never provisioned, so actions/checkout never runs. Log downloads return 404 because no log exists.
• This affects the base branch too: all recent main CI runs (runs 344, 347, 349, 351 — see the last 3 days) fail identically in ~2–5s with zero steps, before any checkout. The workflow's runs-on: ubuntu-latest jobs simply never get a runner.
• A re-run reproduces it: I re-ran this CI run (attempt 2) — same 3s failure, same empty steps, same no-runner state.
• Reported to Hoplite as a platform issue.

What I verified locally (with the pinned bun@1.2.21, exactly as CI runs)

Ran the exact CI commands (bun install --frozen-lockfile, bun run typecheck, bun run lint, bun test) on both this PR's head and a pristine base checkout:

Gate	Base (main)	This PR head
bun install --frozen-lockfile	fails (stale apps/video workspace in lockfile)	passes
bun run typecheck	fails: cortex-sdk 9 pre-existing errors	identical
bun run lint	fails: client 7 pre-existing eslint errors	identical
bun test	5 fail + 1 error	4 fail (env-specific; SMALLEST_API_KEY set, non-TTY)

The head branch introduces zero new failures and actually fixes the one gate that was broken at base (the frozen-lockfile install). The remaining check failures are pre-existing on main and will need to be resolved separately (cortex-sdk's ai@5 vs LanguageModelV3 provider typing, the supercode-cli client's lint debt, and env-specific tests) — they are not regressions from this PR, and cannot be fixed from repository code until the GitHub Actions runner provisioning issue is resolved.

[yashdev9274]

🤖 Supercode AI Review

Summary

This PR performs a dependency audit across 21 workspace package.json manifests and removes 22 zero-reference declarations from 8 files, regenerating bun.lock accordingly. It also drops the stale apps/video workspace block from the lockfile (the directory doesn't exist in the repo) and trims dead transpilePackages entries in apps/web/next.config.ts. The change is net-negative 1,379 lines and has been validated against bun install --frozen-lockfile, typecheck, lint, and bun test.

---

Walkthrough

• root package.json — removes g, vercel, nodemailer, @types/nodemailer from root dependencies/devDependencies.
• apps/web/package.json — removes @hookform/resolvers, @super/claude-sdk, @super/embeddings-sdk, dot, env, pg, @types/mdx, @types/pg, tsx; keeps nodemailer (runtime dep for the web app itself).
• apps/web/next.config.ts — drops @super/claude-sdk and @super/embeddings-sdk from transpilePackages.
• apps/supercode-cli/client/package.json — removes @hookform/resolvers.
• apps/supercode-cli/server/package.json — removes @dodopayments/nextjs, @prisma/driver-adapter-utils, @openrouter/sdk, api, oas, @types/pg.
• apps/superdesign/package.json — removes nanoid.
• packages/auth/package.json — removes kysely.
• bun.lock — regenerated; drops stale apps/video workspace block and all packages no longer reachable.

---

Changes table

File	Summary
package.json	Removes g, vercel, nodemailer, @types/nodemailer from root
apps/web/package.json	Removes 9 unused deps/devDeps
apps/web/next.config.ts	Removes 2 dead transpilePackages entries
apps/supercode-cli/client/package.json	Removes @hookform/resolvers
apps/supercode-cli/server/package.json	Removes 6 unused deps/devDeps
apps/superdesign/package.json	Removes nanoid
packages/auth/package.json	Removes kysely
bun.lock	Regenerated; drops ~1,540 lines including stale apps/video block

---

Findings

• [high] nodemailer kept in apps/web/package.json but removed from root — verify no build-time bleed — apps/web/package.json
  The root package.json had nodemailer and @types/nodemailer as dev/prod deps. This PR removes them from root but keeps nodemailer in apps/web/package.json (as a runtime dep). However, @types/nodemailer is kept in apps/web/package.json as a devDep too. Confirm that nodemailer is genuinely imported in the web app at runtime (e.g., in an API route or server action). If the web app sends email via Resend (which is listed as a dep), nodemailer and its types may themselves be candidates for removal in a follow-up.
  No code change needed here — just a flag to verify before merging.

• [medium] @prisma/driver-adapter-utils removed from apps/supercode-cli/server but @prisma/adapter-pg remains — apps/supercode-cli/server/package.json
@prisma/adapter-pg depends on @prisma/driver-adapter-utils at runtime (it re-exports types from it). In Prisma 7, @prisma/driver-adapter-utils is listed as a direct peer/transitive dep of @prisma/adapter-pg. Removing it from the manifest is fine if bun hoists it correctly via @prisma/adapter-pg's own dep graph, but if the server code imports from @prisma/driver-adapter-utils directly (even via generated types), this could cause a typecheck failure or runtime error in Node environments where hoisting differs. The PR description claims zero direct references — confirm no import ... from '@prisma/driver-adapter-utils' appears in apps/supercode-cli/server/src/**.

  grep -r "@prisma/driver-adapter-utils" apps/supercode-cli/server/src/

• [medium] kysely removed from packages/auth — verify better-auth doesn't require it as a peer — packages/auth/package.json
better-auth supports Kysely as an optional query builder. If any auth configuration in packages/auth/src/ uses createKyselyAdapter or similar kysely-backed adapters, removal will fail at runtime even if tsc passes (because better-auth conditionally imports kysely). The PR description claims zero references; a quick grep is worth confirming:

  grep -r "kysely" packages/auth/src/

• [medium] apps/video workspace dropped from bun.lock but still referenced in root package.json workspaces glob — package.json, bun.lock
  Root package.json has "workspaces": ["apps/*", ...], which would still glob-match a future apps/video directory. The bun.lock regeneration silently dropped it because the directory doesn't exist. This is correct behavior, but the PR description notes that bun install --frozen-lockfile previously failed due to this stale block. Consider explicitly excluding apps/video in the workspaces glob or adding a comment to prevent confusion if the directory is restored:

  "workspaces": [
    "apps/!(video)",
    "apps/supercode-cli/*",
    "packages/*"
  ]

  Or simply document in the PR that apps/video is intentionally absent.

• [low] @openrouter/sdk removed from server devDeps but @openrouter/ai-sdk-provider kept — apps/supercode-cli/server/package.json
  These are distinct packages. @openrouter/ai-sdk-provider is the AI SDK adapter (kept, used via @openrouter/ai-sdk-provider imports). @openrouter/sdk is the raw REST client SDK (removed). Confirmed correct per the PR description — just noting for reviewers that these are intentionally separate.

• [low] configVersion: 1 removed from bun.lock — bun.lock
  The diff shows "configVersion": 1 dropped from the lockfile header. This is a bun version difference artifact (bun 1.2.21 vs 1.3.1). The PR already explains this. Ensure CI uses bun@1.2.21 (pinned in packageManager field) so the lockfile is stable.

• [nit] tsx removed from apps/web devDeps but @vercel/node (in the lockfile) still bundles tsx@4.21.0 — apps/web/package.json
tsx is a transitive dep of @vercel/node (visible in the lockfile: "tsx": "4.21.0" under @vercel/node's deps). Removing it from apps/web's own devDeps is correct — the direct declaration was redundant. No action needed.

---

Risk assessment

Low — All changes are manifest-only dependency removals with no logic changes; the PR author has validated against the full CI matrix (typecheck, lint, bun test) and confirms pre-existing failures are unchanged. The only non-trivial risk is the @prisma/driver-adapter-utils and kysely removals, which are runtime-invisible to tsc if the code paths are conditionally loaded.

---

Test plan

• Run bun install --frozen-lockfile from the repo root and confirm it exits 0.
• Run bun run typecheck — confirm server and cortex-sdk errors are identical to baseline HEAD (pre-existing only).
• Run bun run lint — confirm web app reports same 180 problems as baseline.
• Run bun test — confirm 215 pass / 4 fail, same 4 failures as baseline.
• Grep for direct imports of removed packages in source:
  • grep -r "@prisma/driver-adapter-utils" apps/supercode-cli/server/src/
  • grep -r "kysely" packages/auth/src/
  • grep -r "nanoid" apps/superdesign/src/
  • grep -r "@hookform/resolvers" apps/supercode-cli/client/ apps/web/
• Confirm nodemailer is actually used in apps/web (not replaced entirely by Resend).
• Deploy a preview build of apps/web and verify no runtime import errors on email-related routes.
• Verify bun run build for apps/supercode-cli/server produces a valid dist/main.js.

---

Suggested PR description

What
Removes 22 zero-reference dependency declarations across 8 package.json manifests in the monorepo. Also removes two dead transpilePackages entries in apps/web/next.config.ts and drops a stale apps/video workspace block from bun.lock (directory does not exist in the repo).

Why
Reduces install surface, speeds up CI, and eliminates confusion from declared-but-unused packages. The stale apps/video lockfile block was causing bun install --frozen-lockfile to fail on a clean HEAD.

How tested

• bun install --frozen-lockfile → passes
• bun run typecheck → matches baseline (pre-existing errors in server/cortex-sdk unchanged)
• bun run lint → matches baseline (web app: 180 problems, byte-identical elsewhere)
• bun test → 215 pass / 4 fail; same 4 failures reproduce on pristine HEAD (env/TTY issue, not related to this change)
• Manual grep confirmed zero source references for each removed package

---

Automated review by Supercode · leave a 👍/👎 reaction to rate this review

[usehoplite]

Thanks for the review. Addressed every finding with verification — including a follow-up commit that closes the only remaining grep hit.

[high] nodemailer in apps/web — verified in use

apps/web/lib/email.ts imports nodemailer and builds an SMTP transporter (createTransport against smtp.gmail.com) used by sendWaitlistConfirmation / waitlist routes. resend is a separate path (apps/web/modules/email/resend.ts), so both are legitimately live; root's nodemailer/@types/nodemailer were removed only because the root manifest had zero consumers and web declares its own. @types/nodemailer stays in web as the ambient types for that import (nodemailer ships none).

[medium] @prisma/driver-adapter-utils — zero direct references

grep -r "@prisma/driver-adapter-utils" apps/supercode-cli/server/src/ → 0 hits (verified again just now). The server's generated client imports only @prisma/client-runtime-utils (checked by regenerating prisma generate and grepping the output). The package remains in the root lockfile as a hard dependency of @prisma/adapter-pg@7.8.0 ("@prisma/driver-adapter-utils": "7.8.0"), so runtime/node resolution is guaranteed through bun's hoisting.

[medium] kysely — zero references; retained transitively anyway

grep -r "kysely" packages/auth/src/ → 0 hits. packages/auth uses prismaAdapter (better-auth/adapters/prisma), never a kysely adapter. And kysely remains in the lockfile as a dependency of better-auth itself, so even optional kysely-adapter code paths would resolve if ever enabled.

[medium] apps/video workspaces glob — deliberately unchanged

apps/* is correct as-is: the glob simply doesn't match a directory that doesn't exist. The actual defect (stale apps/video block inside bun.lock, which broke --frozen-lockfile on a clean checkout) is fixed by the regeneration. Adding apps/!(video) would preemptively exclude the directory if it's ever restored, which is speculative; if it returns, bun re-adds the block correctly. Documented.

[low] @openrouter/sdk — confirmed intentional

@openrouter/ai-sdk-provider (kept) is the model adapter used via import { createOpenRouter }; @openrouter/sdk (removed) is the raw REST client with zero imports in this repo. Correct as separate concerns.

[low] configVersion dropped from bun.lock header

Current header is {"lockfileVersion": 1, "workspaces": ...} — exactly what the pinned bun@1.2.21 writes. CI pins bun@1.2.21 (oven-sh/setup-bun + packageManager field), and bun install --frozen-lockfile passes against this lockfile, so the format is CI-stable.

[nit] tsx — confirmed redundant

@vercel/node@5.5.33 appears in the lockfile as an optional peer of inngest (a kept root dep) with its own bundled tsx@4.21.0. Web's direct tsx declaration was only referenced by scripts that no longer exist; removal is correct.

Follow-up commit: b2fa42a — removed the two orphaned nested lockfiles

Your test-plan grep for @hookform/resolvers was matching apps/supercode-cli/client/bun.lock. Investigation confirmed those nested bun.lock files are orphaned: bun governs workspace installs solely by the root lockfile (running bun install inside those directories leaves the nested files untouched), nothing in CI/docker/scripts references them, and they were now stale against the audited manifests (still listing @hookform/resolvers, @prisma/driver-adapter-utils, @types/pg). Since they can't be regenerated by bun (workspace-member installs don't write them) and hand-editing integrity hashes isn't viable, they're removed — bun install --frozen-lockfile still passes (exit 0). All four test-plan greps are now 0 hits across the whole tree.

CI status

Checks still show the GitHub Actions runner-provisioning failure (all jobs complete in ~3s with zero steps executed — runner_id: 0, empty steps, no logs — identical across every main run for the past 3+ days; reproduced on a re-run). The updated head (b2fa42a) has triggered a fresh run; the platform has been notified.

[usehoplite]

CI root cause found: GitHub account is locked due to a billing issue

I extracted the annotations GitHub attaches to the failed checks — the log-less ~3s failures now have an explicit reason:

"The job was not started because your account is locked due to a billing issue."

Confirmed on all three jobs (TypeScript Check, Lint, Test) and on both the original run and the latest run at b2fa42a. This matches the full evidence trail:

• Every job completes in ~3s with zero steps executed, no runner assigned (runner_id: 0), and no log content (log downloads 404 — nothing ever ran).
• Every CI run of this workflow has failed this way since at least July 2026 — runs 56 through 359, across push-to-main and every PR branch. This predates this PR by months and is unrelated to any change in it.
• The workflow file itself is valid: GitHub serves it as active, YAML is well-formed, and it's byte-identical to what local runs use.

This is an account-level billing lock, not a repository issue. Nothing in this PR's code can affect it — the account owner needs to resolve the GitHub billing hold (GitHub → Settings → Billing / support) for hosted Actions runners to provision again. Once the lock is lifted, re-running CI here should execute normally; the branch's local validation (bun install --frozen-lockfile, typecheck, lint, test) passes and the head has no new failures versus base.