feat: add create-prisma next support - #37
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
@next preview published
|
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
* feat: use mongodb-memory-server for local mongo dev Replace the docker-compose helper with a generated scripts/start-mongo.ts that runs mongodb-memory-server, so `db:up` works without Docker. When mongo is selected without --database-url, the helper now writes the start script, pins mongodb-memory-server@^11.1.0 as a devDependency, and sets a package-manager-aware `db:up` script (bun / deno run -A / tsx). No more docker-compose.yml, no db:down. The e2e suite is parameterized across hono + next for both providers (4 tests). Mongo cases scaffold without a databaseUrl, start the generated db:up in the background on a free port, and exercise migrate / seed / verify / build against the in-memory server — so the generated script is itself under test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat: persist mongo dev data across db:up restarts The generated scripts/start-mongo.ts now writes the replica set's data to a real directory (default .mongo-data/, overridable via MONGO_DB_PATH) instead of mongodb-memory-server's temp dir, so seeded users and applied migrations survive between Ctrl+C cycles. The setup helper gitignores .mongo-data, and each template README explains the "delete the folder for a clean slate" escape hatch. E2E tests stay ephemeral by construction: each test scaffolds a fresh project, so its .mongo-data is a fresh directory too. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat: detach db:up and add db:down + db:reset Replace scripts/start-mongo.ts with a scripts/mongo.ts CLI that exposes three subcommands: up (detached child that exits once the replica set prints "ready", PID written to .mongo-data/mongo.pid, logs in .mongo-data/mongo.log), down (SIGTERM the recorded PID, SIGKILL after 10s, idempotent on stale PIDs), and reset (down plus wipe of .mongo-data/). The CLI re-exec's itself with the right runner — bun, deno run -A, or tsx — so it stays correct across the package managers we ship. Cleanup is now an obvious one-liner: db:reset stops mongo and removes the data directory. db:down leaves data in place. The e2e suite is correspondingly simpler: the test just calls `bun run db:up` (returns when ready, MONGO_PORT passed in for collision-free parallelism) and `bun run db:down` in the finally, with no in-test background process management. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: harden local mongo scaffold Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com> * fix: clean up mongo helper data paths Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com> --------- Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
* refactor: model Prisma Next version as a resolved spec Introduce ResolvedPrismaNextSpec + parsePrismaNextVersionSpec so the target Prisma Next version is no longer a module-level constant. The parser recognises pkg-pr-new:<ref> specs alongside npm versions and dist-tags; getPrismaNextPackageSpecifier and getDependencyVersion now accept the resolved spec and emit either name@<spec> or the https://pkg.pr.new/prisma/prisma-next/<name>@<ref> URL form that package managers accept directly. No call sites pass a non-default spec yet; the new shape is what the upcoming --prisma-next-version flag will thread through. * feat: thread --prisma-next-version through scaffolding Add the --prisma-next-version flag and plumb the resolved Prisma Next spec into PrismaSetupContext, writePrismaDependencies, writeCreateTemplateDependencies, and the prisma-next init invocation. Every @prisma-next/* and prisma-next dependency written into package.json — and the npx/dlx/bunx prisma-next@<spec> init command — now honours the spec. With no flag, behaviour is unchanged (latest). Supported specs: - a published npm version (0.10.0, 0.11.0-dev.9, …) for regression / bisect work against the exact version a user filed an issue on; - an npm dist-tag (latest, dev, next, …) for smoke-testing release candidates before they get the latest tag; - pkg-pr-new:<sha|branch|pr-number> for dogfooding open PRs end-to-end through the canonical scaffold path — substitutes the https://pkg.pr.new/prisma/prisma-next/<package>@<ref> URL specifier for every Prisma Next install. Package managers accept URL specifiers in both install argv and package.json, so no special-casing per package manager is needed. The pkg.pr.new path doesn't yet derive a matching skills ref (the upstream prisma-next CLI needs a PRISMA_NEXT_SKILLS_REF override before this is fully wired up); cases 1+2 work end-to-end today and unblock the onboarding-audit regression workflows. * feat: report Prisma Next version spec in create telemetry Add prisma-next-version-kind (default | npm-tag | npm-version | pkg-pr-new) and prisma-next-version-spec to the create command's completion / failure events. The kind is the low-cardinality signal the onboarding audit needs to see which escape hatch users reach for; the spec round-trips the exact string for the long tail of dist-tags, prereleases, and PR refs that can't be summarised by the kind alone.
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
|
Updated in What changed
Verification
Upstream runtime limitationBun 1.3.14 + Mongo remains blocked upstream because BSON calls |
Summary
prisma-next@latest init --no-installas the source of truth for Prisma Next files and starter contracts.minimal,hono,elysia,nest,next,svelte,astro,nuxt, andtanstack-start.minimalthe default template and adds per-template descriptions in the interactive picker.--yesstaying non-provisioning.db:init, migrations, and seed manual only. No generated path auto-runs database setup under prompts or--yes.latestat scaffold time instead of hard-pinning framework versions in create-prisma.@prisma-next/agent-skill, noskillsdependency, noskills:syncscript, and noexperimental_syncinvocation.prisma-next.mdand the upstream Prisma Nextskills/directory.create-prisma@nextreleases.Validation
bun run format:checkbun run typecheckbun run lintbun run buildbun run test:unitbun run test:e2edb:init,db:verify, migration plan/apply, seed, and query script.bun,npm,pnpm, anddenoverifies generated Minimal projects do not includeskills,@prisma-next/agent-skill, orskills:sync.