docs: NPM registry publishing strategy for @ottabase packages

[Copilot]

Comprehensive analysis of splitting monorepo packages to npm registry — covering trade-offs, industry benchmarks, and a concrete rollout plan.

Analysis

• Three options evaluated: keep monorepo (status quo), full npm split, hybrid publish-from-monorepo
• Industry comparison: Vercel, shadcn, tRPC, Drizzle, Mantine, Cloudflare all use the hybrid approach
• Recommendation: Hybrid — keep monorepo, publish curated subset via Changesets

Package Classification

• 🟢 21 packages → publish (general-purpose: utils, cf, queue, db, api, ui-cropper, etc.)
• 🟡 11 packages → publish (ecosystem: ui-shadcn, ottaselect, docs, etc.)
• 🔴 14 packages → keep private (tightly coupled: brand-engine, rbac, notifications, audit)

Tiered Rollout

Tier	Timeline	Count	Criteria
1	Week 1-2	17	Zero internal @ottabase/* deps
2	Week 3-4	12	Depends on Tier 1 only
3	Week 5-6	3	Core ORM/auth packages
4	Later	14	Re-evaluate as they decouple

Infrastructure Changes Documented

• Changesets config (.changeset/config.json) with linked groups and ignore list for private packages
• GitHub Actions publish.yml workflow (changeset-based: pending changesets → version PR → merge → npm publish)
• Per-package package.json additions (publishConfig, files, repository, license)
• .npmrc, LICENSE, npm org setup
• Single-developer workflow: pnpm changeset → push → auto-PR → merge → auto-publish

Key Insight

workspace:* references are automatically converted to semver ranges by pnpm + Changesets at publish time — no manual dep rewiring needed. Local dev stays identical.

---

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