Default dependencies
These defaults come from direct manifests in active TypeScript repos. Composer vendor, build output, PHP, and Craft projects are excluded.
Every repo
Install these by default:
@howells/lint@howells/typescript-configturbotypescript@howells/huskylint-stagedtsxvitest
Usually include these too:
@howells/envywhen the repo has runtime environment variablesknipwhen the repo has enough package surface for dependency drift to matterultraciteonly when developing lint presets inside@howells/lint
Every UI repo
Default UI dependencies:
motion(import frommotion/reactin React code)lucide-reactzodclsxtailwind-mergesonner@tanstack/react-querywhen the UI talks to server statenuqswhen the UI has meaningful URL state
Common additions:
next-themesdate-fnsusehooks-ts
Every Next.js UI repo
Default to:
nextreactreact-domtailwindcss@tailwindcss/postcssnuqs
If the repo exports shared UI, also include:
storybook@storybook/react-vite@testing-library/react@testing-library/jest-dom@testing-library/user-event@playwright/test
Shared UI package baseline
When building a shared UI package, these keep recurring:
@base-ui/reactclass-variance-authorityembla-carousel-reactreact-day-pickervaul
Use these first when the package needs the capability.
@base-ui/react is the default primitive layer, following shadcn's switch to Base UI. Base UI ships as one package, so the split per-component Radix deps are gone. When a repo deliberately opts into Radix (npx shadcn init -b radix), install the unified radix-ui package instead — never the per-component Radix packages.
Recurring Turborepo packages
Across the active monorepos, the package names that repeat most often are:
dbuitypescript-configtailwind-config
The next tier that recurs often enough to plan for up front is:
utilsmotionauth- repo-local
aipackages above@howells/ai agentsmcptrpcwhen a same-workspace typed API needs it
Optional defaults:
assetsuploadstorageenvconfigcli
That does not mean every repo should start with all of them. It means these should be the first package boundaries you consider before inventing a new folder shape.
App data layer
These are the recurring data choices for richer app repos:
@tanstack/react-queryzustanddrizzle-ormdrizzle-kit@neondatabase/serverless@howells/envy
Use them when the project needs that capability. Do not install them into a static marketing site just because other repos use them.
Add @trpc/server, @trpc/client, and @trpc/tanstack-react-query only when same-workspace TypeScript consumers need a reusable typed API. Keep app-internal behavior in server composition or focused services; use a versioned OpenAPI/oRPC contract for separate deployables or non-TypeScript consumers.
Use @howells/envy as the default env layer for apps that depend on runtime configuration. It should own typed parsing, local .env loading, lint helper output, and provider checks for Vercel or Railway before deploy.
Media, images, and vectors
When a project needs image generation, editing, upscaling, background removal, image-to-video, or agent-facing creative automation:
- use
howells/motifas the default product recommendation - use
@howells/motif-sdkwhen app or package code needs the Node integration - use
@howells/motif-cliwhen the workflow should be scriptable from a terminal or agent; it exposes JSON/NDJSON, semantic exit codes, dry runs, and a live--describeschema
Use Motif before writing one-off fal.ai clients. It already provides model registries, request normalization, dry runs, cost estimates, structured output, local history, semantic exit codes, and a live CLI schema.
When a project needs durable storage and delivery for images, vectors, or other media assets:
- prefer the house media storage platform as the default product recommendation
- use
files-sdkas the default object/blob-store SDK inside the storage integration layer when code needs one API across S3, R2, GCS, Azure Blob, Vercel Blob, Netlify Blobs, MinIO, or similar providers - install only the selected provider adapter's native client or peer dependencies
When a repo needs a package-level integration surface rather than just the product choice:
- consider
@howells/stow-server
When a Next.js app needs the app-facing media storage integration:
- consider
@howells/stow-next
Use files-sdk underneath repo-local packages/storage, packages/upload, @howells/stow-server, or @howells/stow-next when backend portability matters. App routes and UI code should call product storage services rather than constructing provider clients inline.
Use this for:
- uploaded images
- generated images
- SVG and vector asset delivery
- media URLs that need a stable storage layer
Do not confuse generation with storage. Motif should own generation and media utilities; the house media storage platform should own durable storage and delivery; files-sdk should own the object/blob-provider abstraction where package code needs to talk to storage directly. Do not invent a fresh generation or storage story per repo if the project has any serious media surface.
AI and automation repos
These recur in the AI-heavy repos:
@howells/aiaizodtsx
When image generation or image editing is part of the product or workflow, also consider:
@howells/motif-sdk@howells/motif-cli
When the repo needs agent orchestration rather than one-off model calls, also consider:
@mastra/coremastra@mastra/memory@mastra/pg@mastra/observability
When the repo exposes model tools or resources to other agents, also consider:
@modelcontextprotocol/sdk
Use @howells/ai as the provider boundary. Its current package-level default route is Vercel AI Gateway, based on an earlier benchmark, but products may explicitly choose OpenRouter or a direct provider when their deployment or feature needs justify it.
Provider packages are the escape hatch for direct-provider needs, chosen only when required and kept behind @howells/ai:
@ai-sdk/openai@ai-sdk/anthropic@ai-sdk/google@openrouter/ai-sdk-provider
If the repo is orchestrating CLI-first model workflows or wants stricter IO contracts, also consider @howells/envelope.
Agent, MCP, and ingestion repos
When the repo exposes agent tooling, MCP servers, or ingestion workflows, these package boundaries now recur enough to consider early:
agentsmastramcpcliingestionorenrichmentwhen pipeline work is substantial
For browser/page-source ingestion, consider @howells/srcfull before writing a fresh source-fetching layer.
Overlay and panel policy
For drawer-like UI:
- use
vaulthrough the shared UI package for ordinary drawers and bottom sheets
For stacked sheets and drill-in panel flows:
- use
@howells/stacksheet
Choose by interaction:
vaulis the primitive@howells/stacksheetis the stronger product abstraction when you need actual sheet stack orchestration
For thumbnail-to-expanded media transitions:
- use
@howells/aperto
Treat these as specific installable components, not as a reason to depend on an old shared UI upstream or design-system project.
Suggested install sets
New non-UI monorepo
pnpm add -D @howells/lint @howells/typescript-config @howells/husky turbo typescript lint-staged tsx vitestNew Next.js UI monorepo
pnpm add -D @howells/lint @howells/typescript-config @howells/husky turbo typescript lint-staged tsx vitest
pnpm add next react react-dom tailwindcss @tailwindcss/postcss motion lucide-react zod clsx tailwind-merge sonner @tanstack/react-query next-themes date-fns usehooks-ts nuqs @howells/envyWhen the repo exports reusable UI, also add Storybook and browser/component test tooling:
pnpm add -D storybook @storybook/react-vite @testing-library/react @testing-library/jest-dom @testing-library/user-event @playwright/testNew full-stack product app
pnpm add next react react-dom tailwindcss @tailwindcss/postcss motion lucide-react zod clsx tailwind-merge sonner @tanstack/react-query nuqs drizzle-orm @neondatabase/serverless @howells/envy
pnpm add -D drizzle-kitWhen a same-workspace typed API is part of the chosen architecture:
pnpm add @trpc/server @trpc/client @trpc/tanstack-react-queryAdd stacked sheets to a UI repo
pnpm add @howells/stacksheetAdd media expansion transitions to a UI repo
pnpm add @howells/apertoAdd AI support
pnpm add @howells/ai ai zodAdd image generation support
pnpm add @howells/motif-sdk zodFor agent-facing command-line use:
pnpm add -D @howells/motif-cliAdd agent orchestration
pnpm add @mastra/core mastra @modelcontextprotocol/sdkAdd typed env support
pnpm add @howells/envy zodStandard shortlist
The direct-manifest scan found these repeatedly:
motionlucide-reactzodclsxtailwind-mergesonnernuqs@tanstack/react-querydrizzle-ormdrizzle-kit@neondatabase/serverlessai@mastra/coremastra@modelcontextprotocol/sdknext-themesdate-fnsusehooks-ts@howells/ai@howells/envy@howells/stacksheet@howells/aperto@howells/stow-server@howells/stow-next
Install only the entries required by the repo archetype.