create-svc 0.1.10 → 0.1.12

package/README.md

@@ -1,43 +1,56 @@
-# create-svc
+# service
 
-`create-svc` is a local backend bootstrap CLI for generating standalone Cloud Run API services with:
+`service` is a local microservice CLI for generating standalone API services and operating them after generation with the same command name.
 
 - a single `microservice` generation path
-- a Bun-first backend path built around `hono` and ConnectRPC
+- explicit deploy target selection: Cloud Run or Cloudflare Workers
+- Go or Bun runtime choices where the target supports them
+- HTTP frameworks (`chi` or `hono`) and ConnectRPC variants
 - standalone package output that does not assume repo bootstrap
-- compatibility with future monorepo use in layouts like `apps/<service>`
-- a real `service.yaml` manifest
-- shared Cloud Run bootstrap, deploy, and cleanup automation
+- a generated `service.config.ts` manifest
+- one `service` CLI for scaffold, create, deploy, migrate, seed, dashboards, doctor, and destroy
 - local Docker Compose Postgres for first-run development
-- Neon-backed remote main, preview, and personal environments
-- GCS-backed image attachments
-- typed HTTP webhook ingress
-- a production API origin at `https://api.<appname>.anmho.com`
+- Neon-backed remote environments
+- a production API origin at `https://api.<service_id>.anmho.com`
 
-Local provisioning intentionally prefers known-good CLIs, especially `gcloud`, over SDK-heavy orchestration for Google Cloud operations.
-Terraform, control planes, and platform consoles are optional advanced paths, not default prerequisites.
+Local provisioning intentionally prefers known-good CLIs over SDK-heavy orchestration where that keeps the generated service easier to inspect and repair.
 
 npm: <https://www.npmjs.com/package/create-svc>
 
 ## Usage
 
 ```bash
-bun create svc my-service
+service create my-service
 ```
 
-or:
+Inside a generated service repo, the same command operates that repo:
 
 ```bash
-bunx create-svc my-service
+cd my-service
+service create
+service deploy
+```
+
+To install from npm:
+
+```bash
+bun add -g create-svc
 ```
 
 For the strict one-command production path:
 
 ```bash
-bun create svc my-service --profile microservice --bootstrap --yes
+service create my-service --yes
 ```
 
-`--profile microservice` is accepted as a compatibility no-op. Full app workspaces live in the private GitHub template repos `anmho/create-app-consumer` and `anmho/create-app-saas`.
+`--profile microservice` is accepted as a compatibility no-op. App workspaces live outside this package in private app template repositories.
+
+By default, a standalone generated service is initialized as a git repository,
+committed with `Initial commit`, created as a private GitHub repository at
+`anmho/<service-name>`, and pushed to `origin/main`. If the target directory is
+inside an existing git worktree, `service` skips git and GitHub setup so the
+parent repository remains in control. Pass `--no-git` to skip all git and GitHub
+side effects.
 
 ## Local Testing
 
@@ -46,15 +59,14 @@ Without publishing to npm:
 ```bash
 bun install
 npm pack
-bunx ./create-svc-*.tgz my-service
+bunx ./create-svc-*.tgz create my-service
 ```
 
 For faster iteration against your working tree:
 
 ```bash
 bun link
-bun link create-svc
-create-svc my-service
+service create my-service
 ```
 
 During scaffold, the generator can discover:
@@ -62,8 +74,8 @@ During scaffold, the generator can discover:
 - accessible GCP projects
 - open billing accounts
 
-Remote `bootstrap` and `deploy` use Neon credentials from `NEON_API_KEY`, or Vault via `VAULT_ADDR` plus `VAULT_TOKEN`, `VAULT_TOKEN_FILE`, or `~/.vault-token`.
-Provider runtime credentials can be supplied through environment variables or Vault paths under `secret/prod/providers/*`; generated Cloud Run services receive runtime values through app-project Secret Manager.
+Generated provisioning commands use Neon credentials from `NEON_API_KEY`, or Vault via `VAULT_ADDR` plus `VAULT_TOKEN`, `VAULT_TOKEN_FILE`, or `~/.vault-token`.
+The base waitlist service keeps provider integrations out of the runtime by default; add provider-specific secrets only when the generated service actually uses that provider.
 
 Before running generated provisioning commands locally, authenticate `gcloud` on the machine:
 
@@ -71,13 +83,11 @@ Before running generated provisioning commands locally, authenticate `gcloud` on
 gcloud auth login
 ```
 
-## Generated Backend Package
+## Generated Service Package
 
 First local run:
 
-```bash
-docker compose up -d
-```
+`bun run migrate`, `make migrate`, `bun run dev`, and `make dev` open Docker Desktop when needed, wait for Docker readiness, and start Docker Compose Postgres before touching the local database.
 
 For Bun variants:
 
@@ -87,9 +97,9 @@ bun run dev
 bun run gen
 bun run lint
 bun run test
-bun run bootstrap
-bun run deploy
-bun run cleanup
+service create
+service deploy
+service destroy
 ```
 
 For Go variants:
@@ -100,25 +110,23 @@ make dev
 make gen
 make lint
 make test
-make bootstrap
-make deploy
-make cleanup
+service create
+service deploy
+service destroy
 ```
 
-The generated package is intended to be consumed by a Next.js web app or a mobile client over HTTPS. In v1, production is expected to live at `https://api.<appname>.anmho.com`, while preview and personal environments keep using deterministic Cloud Run URLs.
+Language-specific tasks such as local running, linting, formatting, testing, and building stay in package scripts or Make targets. Service lifecycle operations are exposed through the generated `service` CLI.
 
-The microservice profile is moving toward a small waitlist/launch service example. The current generated plumbing still includes:
+The generated service is intended to be consumed by a web app, mobile client, or another service over HTTPS. In v1, production is expected to live at `https://api.<service_id>.anmho.com`, while preview and personal environments keep using deterministic platform URLs where appropriate.
 
-- Postgres-backed `users`, `conversations`, `conversation_participants`, and `messages`
-- image attachment upload/finalize plumbing via GCS
-- generic typed webhook ingestion on plain HTTP
+The generated microservice domain is a small waitlist/launch service example with public submit/status APIs and target-specific scheduled work.
 
 ## Development
 
 ```bash
 bun install
 bun test src scripts
-bun run index.ts my-service
+bun run index.ts create my-service
 ```
 
 Validate the generated app matrix against local Docker Compose Postgres:
@@ -129,15 +137,16 @@ bun run validate:generated -- --variant bun-hono
 bun run validate:generated -- --variant go-connectrpc --keep
 ```
 
-The validation harness scaffolds generated apps into ignored `bin/generated/run-*` workspaces, runs the generated public commands, starts the local server, and smoke-tests health or typed ConnectRPC clients where applicable.
+The validation harness scaffolds generated services into ignored `bin/generated/run-*` workspaces, runs the generated public commands, starts the local server, and smoke-tests health or typed ConnectRPC clients where applicable.
 
 ## npm Trusted Publishing
 
 `create-svc` is set up for npm trusted publishing from GitHub Actions, so there is no long-lived npm publish token to store in Vault.
 
 Repository workflow:
+
 - [publish.yml](.github/workflows/publish.yml)
-- Trigger: Git tags matching `v*`
+- Trigger: pushes to `main`, Git tags matching `v*`, or manual `workflow_dispatch`
 - CI runtime: Bun for install/test/typecheck, npm for the final publish step
 
 npm package setup still has to be configured once in the npm UI to trust this repository and workflow:
@@ -151,11 +160,6 @@ npm package setup still has to be configured once in the npm UI to trust this re
    - Workflow filename: `publish.yml`
 5. Save the trusted publisher.
 
-After that, publishing is:
-
-```bash
-git tag v0.1.10
-git push origin v0.1.10
-```
+After that, publishing can be triggered by pushing to `main`, creating a `v*` tag, or running the workflow manually.
 
-The GitHub Actions workflow will authenticate with npm via OIDC and run `npm publish` without an npm token.
+The GitHub Actions workflow authenticates with npm via OIDC and runs `npm publish` without an npm token.

package/index.ts

@@ -1,5 +1,5 @@
 #!/usr/bin/env bun
 
-import { run } from "./src/cli";
+import { runServiceCommand } from "./src/service";
 
-await run(process.argv.slice(2));
+await runServiceCommand(process.argv.slice(2));

package/package.json

@@ -1,19 +1,20 @@
 {
   "name": "create-svc",
-  "version": "0.1.10",
-  "description": "Local backend bootstrap CLI for Bun-first Cloud Run API services with Neon and Vault provisioning.",
+  "version": "0.1.12",
+  "description": "Local microservice bootstrap CLI for Cloud Run and Workers services with Neon-backed data.",
   "module": "index.ts",
   "type": "module",
   "license": "MIT",
   "bin": {
-    "create-svc": "bin/create-svc.mjs",
-    "create-service": "bin/create-svc.mjs"
+    "service": "bin/service.mjs"
   },
   "files": [
-    "bin",
+    "bin/service.mjs",
     "index.ts",
     "src",
     "templates",
+    "!bin/generated",
+    "!templates/**/node_modules",
     "README.md"
   ],
   "scripts": {
@@ -45,12 +46,12 @@
     "@types/bun": "latest"
   },
   "peerDependencies": {
-    "typescript": "^5"
+    "typescript": "^5.9.3"
   },
   "dependencies": {
-    "@clack/prompts": "^1.2.0",
-    "@google-cloud/billing": "^5.1.1",
-    "@google-cloud/resource-manager": "^6.2.1",
+    "@clack/prompts": "^1.4.0",
+    "@google-cloud/billing": "^5.1.2",
+    "@google-cloud/resource-manager": "^6.2.2",
     "@neondatabase/api-client": "^2.7.1",
     "picocolors": "^1.1.1"
   }

package/src/cli.test.ts

@@ -1,6 +1,12 @@
 import { expect, test } from "bun:test";
 import { mkdir } from "node:fs/promises";
-import { assertDiscoveryReady, normalizeValidationResult, parseArgs, validateServiceNameInput } from "./cli";
+import {
+  assertDiscoveryReady,
+  normalizeValidationResult,
+  parseArgs,
+  validateTargetRuntimeFramework,
+  validateServiceNameInput,
+} from "./cli";
 
 test("normalizeValidationResult converts success to undefined", () => {
   expect(normalizeValidationResult(true)).toBeUndefined();
@@ -24,24 +30,36 @@ test("assertDiscoveryReady no longer blocks scaffold when remote discovery is un
   });
 });
 
-test("parseArgs defaults to the microservice profile and treats bootstrap as strict deploy", () => {
+test("parseArgs defaults to microservice and cloudrun target", () => {
   expect(parseArgs(["launch-api", "--yes"])).toMatchObject({
     directory: "launch-api",
     profile: "microservice",
     yes: true,
   });
-  expect(parseArgs(["launch-api", "--yes"]).autoDeploy).toBeUndefined();
-
-  expect(parseArgs(["launch-api", "--profile", "microservice", "--bootstrap"])).toMatchObject({
+  expect(parseArgs(["launch-api", "--target", "workers", "--yes"])).toMatchObject({
     directory: "launch-api",
-    profile: "microservice",
-    autoDeploy: true,
+    target: "workers",
+    yes: true,
   });
+  expect(parseArgs(["launch-api", "--yes"]).autoDeploy).toBeUndefined();
+  expect(parseArgs(["launch-api", "--yes", "--no-git"]).noGit).toBeTrue();
+
+  expect(() => parseArgs(["launch-api", "--profile", "microservice", "--bootstrap"])).toThrow("Unknown argument");
+});
+
+test("parseArgs rejects the removed app profile", () => {
+  expect(() => parseArgs(["tracker", "--profile=app", "--yes"])).toThrow("app profile has moved");
 });
 
-test("parseArgs rejects the moved app profile with private template guidance", () => {
-  expect(() => parseArgs(["tracker", "--profile=app", "--yes"])).toThrow("anmho/create-app-consumer");
-  expect(() => parseArgs(["tracker", "--profile", "app", "--yes"])).toThrow("anmho/create-app-saas");
+test("target/runtime/framework combinations are validated", () => {
+  expect(() => validateTargetRuntimeFramework("cloudrun", "go", "connectrpc")).not.toThrow();
+  expect(() => validateTargetRuntimeFramework("workers", "bun", "hono")).not.toThrow();
+  expect(() => validateTargetRuntimeFramework("workers", "bun", "connectrpc")).toThrow(
+    "Framework connectrpc is not valid for target workers and runtime bun"
+  );
+  expect(() => validateTargetRuntimeFramework("workers", "go", "connectrpc")).toThrow(
+    "Framework connectrpc is not valid for target workers and runtime go"
+  );
 });
 
 test("validateServiceNameInput rejects a taken target directory", async () => {