@rshono/create 1.0.0-rc.2 → 1.0.0-rc.20

package/dist/api.mjs

@@ -52,12 +52,12 @@ __webpack_require__.d(__webpack_exports__, {
 
 ;// CONCATENATED MODULE: ./src/features/combinations.ts
 /**
- * Biome's CSS parser rejects Tailwind's syntax — `@apply` and a `@layer` block are parse errors, not
- * unknown-at-rule warnings — so a project with both needs Biome pointed away from stylesheets. The
- * overlay is a second `biome.json` listed after the first, which is all "later overlay wins" means.
+ * Biome's CSS parser rejects Tailwind's syntax — `@apply` is a parse error, not an unknown-at-rule warning — so
+ * a project with both needs Biome pointed away from stylesheets. The overlay is a second `biome.json` listed
+ * after the first.
  *
- * Narrow on purpose: the alternative was excluding CSS for everybody, which would quietly give up
- * formatting the plain-CSS template that Biome handles perfectly well.
+ * Narrow on purpose: excluding CSS for everybody would give up formatting the plain-CSS template that Biome
+ * handles perfectly well.
  */ const BIOME_TAILWIND = {
     id: 'biome-tailwind',
     overlays: [
@@ -77,24 +77,91 @@ __webpack_require__.d(__webpack_exports__, {
     ] : [];
 }
 
+;// CONCATENATED MODULE: ./src/scripts.ts
+// `features/types.js` rather than `features/index.js`: the deploy feature imports `invoke` from here, and
+// going through the barrel would make that a cycle — types.ts imports nothing.
+/**
+ * The scripts every app gets, whatever it targets.
+ *
+ * `start`, `preview` and `deploy` are not here: each means something different per platform, so the deploy
+ * target contributes its own. The three names are a contract the targets keep, which is what lets the README
+ * describe an app it was not written for:
+ *
+ * - **`start`** runs a build that already exists and never makes one — what a host's own start command calls.
+ * - **`preview`** builds, then runs the result here, so the production build is answerable without deploying.
+ * - **`deploy`** builds, then ships it — where the platform has one command that does the shipping.
+ */ const BASE_SCRIPTS = {
+    dev: 'rshono dev',
+    build: 'rshono build',
+    typecheck: 'tsc --noEmit'
+};
+/**
+ * Every script the app gets, in the order they are written: the base ones, then each feature's. The manifest and
+ * the README's command table are both this, so neither can document a script the other lacks.
+ */ function buildScripts(features) {
+    const scripts = {
+        ...BASE_SCRIPTS
+    };
+    for (const feature of features)Object.assign(scripts, feature.scripts);
+    return scripts;
+}
+/** The gloss for each base script, in the README's command table. `build` names the target it is for. */ function baseScriptHelp(deploy) {
+    return {
+        dev: 'dev server with HMR, http://localhost:3000',
+        build: `production build for ${deploy}`,
+        typecheck: 'tsc --noEmit'
+    };
+}
+/**
+ * Script names a package manager has a command of its own for: `pnpm deploy` runs pnpm's workspace-deploy and
+ * never looks at the manifest. These get the explicit `run` form, which all four managers accept.
+ */ const SHADOWED = new Set([
+    'deploy'
+]);
+/** How to type one of the app's scripts with this package manager — `pnpm dev`, but `npm run dev`. */ function invoke(pm, script) {
+    return `${SHADOWED.has(script) ? `${pm.name} run` : pm.run} ${script}`;
+}
+/**
+ * The README's command table: one line per script, with the command to type and a one-line gloss. A script whose
+ * feature supplies no `scriptHelp` is left out — that is how `format:check` stays out of a table about running
+ * the app — and covered by the line pointing at `package.json`.
+ */ function scriptTable(answers, features, pm) {
+    const help = baseScriptHelp(answers.deploy);
+    for (const feature of features)Object.assign(help, feature.scriptHelp);
+    const documented = Object.keys(buildScripts(features)).filter((name)=>help[name]);
+    const width = Math.max(...documented.map((name)=>invoke(pm, name).length));
+    return documented.map((name)=>`${invoke(pm, name).padEnd(width)}  # ${help[name]}`).join('\n');
+}
+/**
+ * The command that gets this app into production, as a sentence — the README's deploy step and the closing
+ * summary's, so the two cannot name different commands.
+ *
+ * Read off the scripts rather than the target, so a target that gains a `deploy` gains the sentence with it.
+ */ function deployStep(features, pm) {
+    const scripts = buildScripts(features);
+    if (scripts.deploy) return `\`${invoke(pm, 'deploy')}\` does the build and the upload in one step.`;
+    if (scripts.start) return `\`${invoke(pm, 'start')}\` runs that build wherever you host it, and never makes one.`;
+    if (scripts.preview) return `\`${invoke(pm, 'preview')}\` runs the build here, so you can check it first.`;
+    return `\`${invoke(pm, 'build')}\` produces it; getting it there is yours to script.`;
+}
+
 ;// CONCATENATED MODULE: ./src/generated/framework.ts
 // GENERATED by scripts/codegen.mjs from packages/core — do not edit. Run `pnpm --filter @rshono/create codegen`.
-/** The framework release a scaffolded app is pinned to: this package and rshono ship together. */ const RSHONO_VERSION = '1.0.0-rc.2';
+/** The framework release a scaffolded app is pinned to: this package and rshono ship together. */ const RSHONO_VERSION = '1.0.0-rc.20';
 /**
- * The Node range rshono itself declares, restated in every scaffolded app's `engines` — so a CI image
- * or a contributor on an older Node hears it from their package manager rather than from a stack trace.
- */ const NODE_ENGINE = '>=22.1.0';
+ * The Node range rshono declares, restated in every scaffolded app's `engines` — so a CI image or a contributor
+ * on an older Node hears it from their package manager rather than from a stack trace.
+ */ const NODE_ENGINE = '>=22.18.0';
 /**
- * The dependency versions rshono is tested against, copied from its own manifest. Exact where it is
- * exact — React's RSC internals are coupled across builds, and a generated app has no workspace
- * overrides to fall back on.
+ * The dependency versions rshono is tested against, copied from its own manifest. Exact where it is exact:
+ * React's RSC internals are coupled across builds, and a generated app has no workspace overrides.
  */ const FRAMEWORK_DEPS = {
-    hono: '^4.12.31',
+    hono: '^4.13.5',
     react: '19.2.8',
     'react-dom': '19.2.8',
     typescript: '^7.0.2',
-    '@types/node': '^26.1.1',
-    '@types/react': '^19.2.17'
+    '@types/node': '^26.4.0',
+    '@types/react': '^19.2.18'
 };
 /** Every `deploy` target the installed framework knows, with the command that ships what it built. */ const DEPLOY_TARGETS = [
     {
@@ -105,22 +172,10 @@ __webpack_require__.d(__webpack_exports__, {
         name: 'cloudflare',
         hint: 'deploy with `wrangler deploy`'
     },
-    {
-        name: 'bun',
-        hint: 'run `bun dist/server/main.mjs`'
-    },
-    {
-        name: 'deno',
-        hint: 'run `deno serve -A dist/server/main.mjs`'
-    },
     {
         name: 'vercel',
         hint: 'deploy with `vercel deploy --prebuilt`'
     },
-    {
-        name: 'netlify',
-        hint: 'deploy with `netlify deploy --build=false --dir=.netlify/publish`'
-    },
     {
         name: 'aws-lambda',
         hint: 'zip dist/ with the handler at dist/server/main.mjs'
@@ -132,14 +187,12 @@ __webpack_require__.d(__webpack_exports__, {
 /** Passed straight through, so everything generated from the framework reaches the rest of the package here. */ 
 /** The framework range a scaffolded app gets. The two packages are released together, so this is ours. */ const RSHONO_RANGE = `^${RSHONO_VERSION}`;
 /**
- * Versions for the optional tooling the features can add — the one place in this package where a
- * dependency range is typed out by hand, because none of these are things the framework itself
- * declares. Everything a *scaffolded app* needs to run rshono comes from {@link FRAMEWORK_DEPS},
- * which is generated from rshono's own manifest and must not be edited here.
+ * Versions for the optional tooling the features can add — the one place in this package where a range is typed
+ * by hand, because the framework declares none of these. Everything a scaffolded app needs to *run* rshono comes
+ * from {@link FRAMEWORK_DEPS}, generated from rshono's own manifest.
  *
- * Ranges are caret, not exact: these are the app's own dev tools, and a scaffold made six months from
- * now should pick up their patch releases rather than pinning whatever was current the day this file
- * was last touched.
+ * Caret ranges, not exact: these are the app's own dev tools, and a scaffold made six months from now should
+ * pick up their patch releases.
  */ const TOOL_VERSIONS = {
     tailwindcss: '^4.3.3',
     '@tailwindcss/postcss': '^4.3.3',
@@ -151,126 +204,148 @@ __webpack_require__.d(__webpack_exports__, {
     oxlint: '^1.76.0',
     oxfmt: '^0.61.0',
     eslint: '^10.8.0',
-    // ESLint's own recommended JavaScript rules, which typescript-eslint layers on top of rather than
-    // replaces, and the rules of hooks — the one class of React mistake no type checker sees.
+    // ESLint's recommended JavaScript rules, which typescript-eslint layers on rather than replaces, and the rules
+    // of hooks — the one class of React mistake no type checker sees.
     '@eslint/js': '^10.0.1',
     'typescript-eslint': '^8.65.0',
     'eslint-plugin-react-hooks': '^7.1.1',
     wrangler: '^4.115.0'
 };
 /**
- * The TypeScript an ESLint app pins, in place of the framework's own — the one deliberate exception to
- * {@link FRAMEWORK_DEPS}, and the reason it is spelled out here.
- *
- * typescript-eslint reads TypeScript's compiler API directly rather than through a stable interface, so
- * it accepts `typescript >=4.8.4 <6.1.0` and nothing above. `~6.0.3` is the newest that satisfies it:
- * patch releases of 6.0, no minor. The framework itself stays on the TypeScript it is tested against —
- * rshono's declarations compile the same under either, which is what makes this pin an app's business
- * and not the framework's.
+ * The TypeScript an ESLint app pins in place of the framework's own — the one deliberate exception to
+ * {@link FRAMEWORK_DEPS}.
  *
- * When upstream widens the range, this constant and the ESLint feature's use of it are what to delete.
+ * typescript-eslint reads TypeScript's compiler API directly, so it accepts `>=4.8.4 <6.1.0` and nothing above;
+ * `~6.0.3` is the newest that satisfies it. rshono's declarations compile the same under either, which is what
+ * makes this the app's business. When upstream widens its range, this constant is what to delete.
  */ const ESLINT_TYPESCRIPT = '~6.0.3';
 
 ;// CONCATENATED MODULE: ./src/features/deploy.ts
 
+
 /**
- * What a deploy target adds beyond the `deploy` line in `rshono.config.ts` — which is the build's job
- * to read, and the template's to carry.
+ * What a deploy target adds beyond the `deploy` line in `rshono.config.ts`, which the template carries.
  *
- * Deliberately thin. The framework already knows how to arrange its own output for every platform, and
- * `rshono build` writes the one platform config that has to exist (`wrangler.jsonc`, with the
- * `compatibility_date` of the day it ran) if the project has none. Generating a second copy here would
- * be a copy that goes stale.
+ * Thin on purpose: the framework arranges its own output for every platform, and `rshono build` writes the one
+ * platform config that has to exist. So a target contributes the commands that run and ship the build, the CLI
+ * they need, the directories to gitignore, and a note for the step no command covers.
  *
- * So a target contributes only what is true of it: the command that runs or ships the build, the CLI
- * that command needs installed locally, the directories its platform leaves behind for `.gitignore`, and
- * a note for the step no command covers. Several contribute just one of those.
- */ const DEPLOY_FEATURES = {
-    // Where a Node build goes from here is a Dockerfile or a process manager, neither of which this can
-    // guess — so the target contributes only the command that runs what was built.
-    node: {
-        id: 'deploy-node',
-        scripts: {
-            start: 'rshono start'
-        }
-    },
-    // `rshono start` is the Node target's launcher and refuses a build made for another platform, so
-    // these two get the command their own runtime uses under the same script name.
-    bun: {
-        id: 'deploy-bun',
-        scripts: {
-            start: 'bun dist/server/main.mjs'
-        }
-    },
-    deno: {
-        id: 'deploy-deno',
-        scripts: {
-            start: 'deno serve -A dist/server/main.mjs'
-        }
-    },
-    cloudflare: {
-        id: 'deploy-cloudflare',
-        devDependencies: {
-            wrangler: TOOL_VERSIONS.wrangler
-        },
-        // wrangler brings workerd, whose install script only picks the platform binary out of the optional
-        // dependency that already carries it — `workerd --version` answers without it having run.
-        allowBuilds: {
-            workerd: false
-        },
-        scripts: {
-            deploy: 'rshono build && wrangler deploy'
+ * What the three script names promise is documented above `BASE_SCRIPTS` in `scripts.ts`. Only `node` has a
+ * `start` — `rshono start` refuses a bundle built for anywhere else — and it needs no `preview`, since `build`
+ * then `start` already is one.
+ */ function deployFeatures(pm) {
+    const build = invoke(pm, 'build');
+    return {
+        // Where a Node build goes next is a Dockerfile or a process manager, neither of which this can guess.
+        node: {
+            id: 'deploy-node',
+            scripts: {
+                start: 'rshono start'
+            },
+            scriptHelp: {
+                start: 'run the build that exists — what your host calls'
+            },
+            platformSetup: [
+                'The two commands a host asks for:',
+                '',
+                `- **Build** — \`${pm.name} install && ${build}\``,
+                `- **Start** — \`${invoke(pm, 'start')}\``,
+                '',
+                `In a Dockerfile, the same pair: \`RUN ${build}\`, then \`CMD ["${pm.name}", "start"]\`.`
+            ].join('\n')
         },
-        gitignore: [
-            '.wrangler/'
-        ],
-        notes: [
-            'The first build writes wrangler.jsonc — yours to edit after that.'
-        ]
-    },
-    vercel: {
-        id: 'deploy-vercel',
-        scripts: {
-            deploy: 'rshono build && vercel deploy --prebuilt'
+        cloudflare: {
+            id: 'deploy-cloudflare',
+            devDependencies: {
+                wrangler: TOOL_VERSIONS.wrangler
+            },
+            // The only two install scripts a scaffolded app can end up with, and wrangler brings both. Each merely
+            // picks the platform binary out of the optional dependency already carrying it, so neither needs to run.
+            allowBuilds: {
+                esbuild: false,
+                workerd: false
+            },
+            // `wrangler dev` is the one preview that runs the code in workerd rather than Node. Both scripts read the
+            // wrangler.jsonc the build wrote, so nothing here has to know where the bundle went.
+            scripts: {
+                preview: 'rshono build && wrangler dev',
+                deploy: 'rshono build && wrangler deploy'
+            },
+            scriptHelp: {
+                preview: 'build, then run it in workerd — port 8787',
+                deploy: 'build, then ship it to Cloudflare'
+            },
+            gitignore: [
+                '.wrangler/'
+            ],
+            notes: [
+                'The first build writes wrangler.jsonc — yours to edit after that.'
+            ],
+            platformSetup: [
+                `Building from a git repo instead: set Workers Builds' **Build command** to \`${build}\`.`,
+                'Its deploy command already defaults to `npx wrangler deploy`, and it installs dependencies itself.'
+            ].join('\n')
         },
-        gitignore: [
-            '.vercel/'
-        ],
-        notes: [
-            '--prebuilt uploads what rshono build assembled; the platform must not rebuild it.'
-        ]
-    },
-    netlify: {
-        id: 'deploy-netlify',
-        scripts: {
-            deploy: 'rshono build && netlify deploy --build=false --dir=.netlify/publish'
+        vercel: {
+            id: 'deploy-vercel',
+            // `--prod` because the script is called `deploy`: without it the CLI uploads to a throwaway preview URL.
+            // `preview` is a Node build run here — the platform cannot run its own prebuilt output on your machine.
+            scripts: {
+                preview: 'rshono build --deploy node && rshono start',
+                deploy: `rshono build && ${pm.dlx} vercel deploy --prebuilt --prod`
+            },
+            scriptHelp: {
+                preview: 'build for Node and run that here',
+                deploy: 'build, then upload it to production'
+            },
+            gitignore: [
+                '.vercel/'
+            ],
+            notes: [
+                '--prebuilt uploads what rshono build assembled; the platform must not rebuild it.',
+                'Drop --prod from the deploy script for a preview URL instead.'
+            ],
+            platformSetup: [
+                `Deploying from CI instead: the same \`${invoke(pm, 'deploy')}\`, with \`VERCEL_ORG_ID\`, \`VERCEL_PROJECT_ID\``,
+                'and a CLI token in the environment.',
+                '',
+                `If you let Vercel build the repo itself, set **Framework Preset** to Other — \`hono\` is otherwise`,
+                `detected as the Hono preset — and **Build Command** to \`${build}\`.`
+            ].join('\n')
         },
-        gitignore: [
-            '.netlify/'
-        ]
-    },
-    'aws-lambda': {
-        id: 'deploy-aws-lambda',
-        notes: [
-            'Use a Function URL in RESPONSE_STREAM mode — a buffered invoke mode drops the streaming.'
-        ]
-    }
-};
-function deployFeature(target) {
-    return DEPLOY_FEATURES[target];
+        'aws-lambda': {
+            id: 'deploy-aws-lambda',
+            // No CLI to wrap and no upload to guess at, but `preview` still applies: the bundle is a Node handler.
+            scripts: {
+                preview: 'rshono build --deploy node && rshono start'
+            },
+            scriptHelp: {
+                preview: 'build for Node and run that here'
+            },
+            notes: [
+                'Use a Function URL in RESPONSE_STREAM mode — a buffered invoke mode drops the streaming.'
+            ],
+            platformSetup: [
+                `There is no settings page here; the upload is yours to script. A job needs \`${pm.name} install && ${build}\`,`,
+                'then the function package: `dist/` and nothing else, with the handler at `dist/server/main.mjs`. Your',
+                'dependencies are compiled into the bundle for this target, so no `node_modules` is uploaded — which also',
+                'means a native addon fails the build here rather than the deploy.'
+            ].join('\n')
+        }
+    };
+}
+function deployFeature(target, pm) {
+    return deployFeatures(pm)[target];
 }
 
 ;// CONCATENATED MODULE: ./src/features/quality.ts
 
 /**
- * The formatter and linter features. Biome answers to both slots and appears once — `selectFeatures`
- * deduplicates by `id`, so `formatter: 'biome', linter: 'biome'` contributes one set of files, one
- * dependency and one pair of scripts.
+ * The formatter and linter features. Biome answers to both slots and appears once, because `selectFeatures`
+ * deduplicates by `id`.
  *
- * A formatter brings `format:check` beside `format`, because the writing half and the CI half want
- * different exit-code behaviour: `format` rewrites files, `format:check` fails instead. A linter brings
- * `lint:fix` beside `lint`, for the same reason in the other direction — `lint` is already the failing
- * one. Biome adds a `check` of its own, which is the pair of them in a single pass.
+ * Each brings a pair of scripts, since the writing half and the CI half want different exit codes: `format`
+ * rewrites and `format:check` fails, `lint:fix` rewrites and `lint` fails. Biome's `check` is both in one pass.
  */ const PRETTIER = {
     id: 'prettier',
     overlays: [
@@ -312,11 +387,9 @@ const OXLINT = {
 };
 /**
  * The one feature that changes a dependency the framework otherwise decides: typescript-eslint cannot be
- * installed alongside the TypeScript rshono is tested against, so an ESLint app pins the newest one its
- * peer range accepts (see {@link ESLINT_TYPESCRIPT}). Every other preset leaves TypeScript alone.
- *
- * The rules are type-aware, which is the reason to reach for ESLint over a syntax-only linter at all —
- * so the config it ships hands the whole program to the parser rather than linting file by file.
+ * installed alongside the TypeScript rshono is tested against, so an ESLint app pins the newest its peer range
+ * accepts (see {@link ESLINT_TYPESCRIPT}). Its rules are type-aware — the reason to reach for ESLint at all —
+ * so the config it ships hands the parser the whole program.
  */ const ESLINT = {
     id: 'eslint',
     overlays: [
@@ -332,6 +405,12 @@ const OXLINT = {
     scripts: {
         lint: 'eslint .',
         'lint:fix': 'eslint . --fix'
+    },
+    // The pin is invisible from the command line, and its consequence is not: the rules reason about the
+    // program through an older compiler than the one that builds it, so a fix can produce code `tsc` rejects.
+    // The generated eslint.config.mjs explains why; the README's table is where someone reads what to type.
+    scriptHelp: {
+        'lint:fix': 'apply what it can — then run typecheck, see eslint.config.mjs'
     }
 };
 const BIOME = {
@@ -372,14 +451,12 @@ function linterFeature(linter) {
 ;// CONCATENATED MODULE: ./src/features/styling.ts
 
 /**
- * Tailwind is a PostCSS plugin and nothing more, which is the whole of this feature: four packages, and
- * an overlay carrying the `postcss.config.mjs` naming the plugin, an `rshono.config.ts` whose `rspack`
- * hook puts postcss-loader in front of the CSS parser, a Tailwind entry stylesheet, and the two views
- * written in utilities instead of classes of their own.
+ * Tailwind is a PostCSS plugin and nothing more, which is the whole of this feature: four packages, plus an
+ * overlay carrying `postcss.config.mjs`, an `rshono.config.ts` whose `rspack` hook puts postcss-loader in front
+ * of the CSS parser, a Tailwind entry stylesheet, and the two views rewritten in utilities.
  *
- * `postcss` and `postcss-loader` are the app's dependencies rather than the framework's — rshono
- * compiles CSS natively and has no PostCSS in it, so an app that does not want a plugin chain does not
- * install one.
+ * `postcss` is the app's dependency rather than the framework's: rshono compiles CSS natively, so an app that
+ * wants no plugin chain installs none.
  */ const TAILWIND = {
     id: 'tailwind',
     overlays: [
@@ -402,12 +479,14 @@ function stylingFeature(styling) {
 
 
 /**
- * The features a set of answers selects, in application order — so an overlay listed later wins a file
- * both of them ship. Deduplicated by `id`, which is what lets one feature answer two questions (Biome
- * is both the formatter and the linter) without contributing twice.
- */ function selectFeatures(answers) {
+ * The features a set of answers selects, in application order — so an overlay listed later wins a file both
+ * ship. Deduplicated by `id`, which is what lets one feature answer two questions (Biome is both formatter and
+ * linter) without contributing twice.
+ *
+ * `pm` reaches the deploy target because one script has to name the runner that fetches an uninstalled CLI.
+ */ function selectFeatures(answers, pm) {
     const selected = [
-        deployFeature(answers.deploy),
+        deployFeature(answers.deploy, pm),
         stylingFeature(answers.styling),
         formatterFeature(answers.formatter),
         linterFeature(answers.linter),
@@ -426,9 +505,8 @@ function stylingFeature(styling) {
 ;// CONCATENATED MODULE: ./src/options.ts
 
 /*
- * The names each option accepts, spelled once. The types below are derived from them, the CLI validates
- * its flags against them and prints them in `--help`, and `pm.ts` recognises a package manager by them
- * — so a name added here reaches all three without a second list to remember.
+ * The names each option accepts, spelled once: the types below are derived from them, the CLI validates its
+ * flags against them and prints them in `--help`, and `pm.ts` recognises a package manager by them.
  */ const FORMATTER_NAMES = [
     'prettier',
     'biome',
@@ -489,20 +567,26 @@ const QUALITY_PRESETS = [
     }
 ];
 /**
- * Turns whatever the user typed into a name npm will accept, or returns `null` when nothing usable is
- * left. Lowercasing and replacing runs of invalid characters covers the ordinary cases (`My App`,
- * `my_app`); a scoped name is kept intact, since `@scope/name` is legal.
+ * Turns whatever the user typed into a name npm will accept, or `null` when nothing usable is left.
+ * Lowercasing and replacing runs of invalid characters covers the ordinary cases (`My App`, `my_app`).
+ *
+ * The promise is checked rather than assumed: the result goes through {@link isValidPackageName} on the way
+ * out. It used to be spelled as a rule per character class here and the check made again by the caller, which
+ * left the exported function able to return a name npm refuses — `_leading` was one, because a leading
+ * underscore is stripped by npm's rule and not by this one.
  */ function toPackageName(input) {
     const trimmed = input.trim().replace(/^\.\/+/, '').replace(/\/+$/, '');
     if (!trimmed || trimmed === '.') return null;
-    // A scoped name is a name, not a path: `@scope/pkg` stays whole rather than becoming `pkg`. Anything
-    // else is a path, and the last segment is the one that names the project.
+    // A scoped name is a name, not a path: `@scope/pkg` stays whole. Anything else is a path, whose last
+    // segment names the project.
     const scoped = /^@[^\\/]+[\\/][^\\/]+$/.test(trimmed);
     const base = scoped ? trimmed : trimmed.split(/[\\/]/).filter(Boolean).pop() ?? '';
     if (!base) return null;
-    const name = base.toLowerCase().replace(/[\\/]/g, '/').replace(/[^a-z\d\-._~/@]+/g, '-').replace(/^-+/, '').replace(/-+$/, '');
-    if (!name || name === '@' || !scoped && name.startsWith('.')) return null;
-    return name.slice(0, 214);
+    const name = base.toLowerCase().replace(/[\\/]/g, '/').replace(/[^a-z\d\-._~/@]+/g, '-')// `_` alongside `-`: npm refuses a leading underscore too, and it is what `My_App` and `_internal` leave
+    // behind once the invalid runs are replaced.
+    .replace(/^[-_]+/, '').replace(/-+$/, '');
+    const trimmedName = name.slice(0, 214);
+    return isValidPackageName(trimmedName) ? trimmedName : null;
 }
 /** npm's own rule, narrowed to what we ever generate: no uppercase, no leading dot or underscore. */ function isValidPackageName(name) {
     return /^(?:@[a-z\d\-*~][a-z\d\-*._~]*\/)?[a-z\d\-~][a-z\d\-._~]*$/.test(name) && name.length <= 214;
@@ -514,15 +598,7 @@ const QUALITY_PRESETS = [
 
 ;// CONCATENATED MODULE: ./src/pkg.ts
 
-/**
- * The scripts every app gets. `start` is not among them, because it means something different per
- * platform: the three targets that run the build themselves — node, bun, deno — each contribute their
- * own, and a platform target contributes a `deploy` instead, where its platform has one command to give.
- */ const BASE_SCRIPTS = {
-    dev: 'rshono dev',
-    build: 'rshono build',
-    typecheck: 'tsc --noEmit'
-};
+
 /** Field order in the emitted file — the conventional reading order, and stable so snapshots are too. */ const FIELD_ORDER = [
     'name',
     'version',
@@ -538,48 +614,29 @@ function sorted(record) {
     return Object.fromEntries(Object.entries(record).sort(([a], [b])=>a < b ? -1 : 1));
 }
 /**
- * The install script every app inherits, from the framework rather than from anything it chose. tsx
- * reads `rshono.config.ts` through esbuild, and esbuild's script only picks the platform binary out of
- * the optional dependency that already carries it — rshono's own repo denies it for the same reason.
- */ const BASE_ALLOW_BUILDS = {
-    esbuild: false
-};
-/**
- * pnpm's settings for the new app — written for pnpm and for nobody else.
- *
- * It exists for one field. A dependency with an install script is a question pnpm will not answer on its
- * own: it fails the install, and fails every `pnpm dev` after it, until the project has said whether the
- * script should run. None of the ones an rshono app inherits need to (each is a native package whose
- * binary arrives as an optional dependency), so a fresh app carries the answer rather than meeting
- * `pnpm approve-builds` before it has rendered a page once.
+ * pnpm's settings for the new app, or `null` when no feature has anything to put in them.
  *
- * In this file rather than under a `pnpm` key in `package.json`, which pnpm 11 no longer reads, single-
- * package projects included. What lands here is a decision about *this* app: a scaffolded file the app
- * owns from then on, not something the framework reaches back into.
+ * It exists for one field, `allowBuilds`: pnpm fails an install until the project has said whether a
+ * dependency's install script should run. Nothing rshono installs has one, so most apps get no file. A file
+ * rather than a `pnpm` key in `package.json`, which pnpm 11 no longer reads.
  */ function buildPnpmSettings(features) {
-    const allowBuilds = {
-        ...BASE_ALLOW_BUILDS
-    };
+    const allowBuilds = {};
     for (const feature of features)Object.assign(allowBuilds, feature.allowBuilds);
+    const entries = Object.entries(sorted(allowBuilds));
+    if (entries.length === 0) return null;
     return [
         '# Which dependencies may run an install script. pnpm runs none it has not been told about, and',
         '# fails the install rather than skip one quietly — so anything added later belongs here too.',
         '# `false` means the script was looked at: these ship their real binary as an optional dependency.',
         'allowBuilds:',
-        ...Object.entries(sorted(allowBuilds)).map(([name, allowed])=>`  ${name}: ${allowed}`),
+        ...entries.map(([name, allowed])=>`  ${name}: ${allowed}`),
         ''
     ].join('\n');
 }
 /**
- * Assembles `package.json` from the answers and whatever the selected features contribute.
- *
- * Dependencies are sorted by name and scripts are left in contribution order (the base ones, then each
- * feature's, in the order features were selected) — so two runs with the same answers produce byte-
- * identical output, which is what makes the generated manifest snapshot-testable.
+ * Assembles `package.json` from the answers and whatever the selected features contribute. Dependencies are
+ * sorted and scripts keep {@link buildScripts}'s order, so two runs with the same answers are byte-identical.
  */ function buildPackageJson(answers, features, pm) {
-    const scripts = {
-        ...BASE_SCRIPTS
-    };
     const dependencies = {
         '@rshono/core': RSHONO_RANGE,
         hono: FRAMEWORK_DEPS.hono,
@@ -592,7 +649,6 @@ function sorted(record) {
         typescript: FRAMEWORK_DEPS.typescript
     };
     for (const feature of features){
-        Object.assign(scripts, feature.scripts);
         Object.assign(dependencies, feature.dependencies);
         Object.assign(devDependencies, feature.devDependencies);
     }
@@ -605,12 +661,12 @@ function sorted(record) {
         engines: {
             node: NODE_ENGINE
         },
-        scripts,
+        scripts: buildScripts(features),
         dependencies: sorted(dependencies),
         devDependencies: sorted(devDependencies)
     };
-    // Only when the environment told us the exact version: `packageManager` pins the tool for Corepack,
-    // and a guess at the version is worse than leaving the field out.
+    // Only when the environment told us the exact version: this field pins the tool for Corepack, and a guess is
+    // worse than leaving it out.
     if (pm.version) manifest.packageManager = `${pm.name}@${pm.version}`;
     const ordered = Object.fromEntries(FIELD_ORDER.filter((field)=>field in manifest).map((field)=>[
             field,
@@ -622,23 +678,22 @@ function sorted(record) {
 ;// CONCATENATED MODULE: ./src/render.ts
 
 /**
- * `{{NAME}}`, and not the `__NAME__` this used to be. A template is a real file that real tools run
- * over, and in markdown `__NAME__` *is* strong emphasis — Prettier rewrites it to `**NAME**`, which
- * turns a token into literal text that no substitution will ever match again. `{{…}}` means nothing to
- * any of the formats these templates are written in.
+ * `{{NAME}}`, not `__NAME__`: in markdown the latter is strong emphasis, so Prettier rewrites it to `**NAME**`
+ * and the token stops matching. `{{…}}` means nothing to any format these templates are written in.
  */ const TOKEN_PATTERN = /\{\{[A-Z][A-Z\d_]*\}\}/g;
-function tokensFor(answers, pm) {
+function tokensFor(answers, features, pm) {
     return {
         '{{PROJECT_NAME}}': answers.packageName,
         '{{DEPLOY_TARGET}}': answers.deploy,
-        '{{DEPLOY_HINT}}': deployHint(answers.deploy),
-        '{{PM_RUN}}': pm.run
+        // From the features rather than the answers, because all three are about the scripts the app actually got.
+        '{{SCRIPT_TABLE}}': scriptTable(answers, features, pm),
+        '{{DEPLOY_STEP}}': deployStep(features, pm),
+        '{{PLATFORM_SETUP}}': features.map((feature)=>feature.platformSetup ?? '').join('')
     };
 }
 /**
- * Substitutes tokens, and throws on one it doesn't know — a typo in a template would otherwise ship a
- * literal `{{PORJECT_NAME}}` into somebody's new app, which no test of the generator's logic would
- * catch.
+ * Substitutes tokens, and throws on one it does not know — a typo in a template would otherwise ship a literal
+ * `{{PORJECT_NAME}}` into somebody's new app, which no test of the generator's logic would catch.
  */ function render(contents, tokens, source) {
     return contents.replace(TOKEN_PATTERN, (token)=>{
         const value = tokens[token];
@@ -668,12 +723,9 @@ function readTemplateDir(dir) {
     return files;
 }
 /**
- * `_gitignore` → `.gitignore`, and so on for every dotfile.
- *
- * npm strips a literal `.gitignore` out of a published tarball, so a template cannot simply contain
- * one — the file would exist in the repo, pass every local test, and be missing from the package
- * everybody actually installs. Naming them with an underscore and renaming here is the long-standing
- * fix. It applies to the basename only, so `src/lib/_x.ts` is a dotfile but `templates/_x/y.ts` is not.
+ * `_gitignore` → `.gitignore`, and so on for every dotfile: npm strips a literal `.gitignore` out of a
+ * published tarball, so a template that contained one would pass every local test and be missing from the
+ * package everybody installs. The basename only, so `templates/_x/y.ts` is left alone.
  */ function undotted(path) {
     const segments = path.split(posix.sep);
     const name = segments.pop();
@@ -682,22 +734,19 @@ function readTemplateDir(dir) {
         name.startsWith('_') ? `.${name.slice(1)}` : name
     ].join(posix.sep);
 }
-/**
- * A feature's `.gitignore` lines, appended under a heading naming it — so somebody reading the file six
- * months later can tell why `.wrangler/` is in there.
- */ function appendGitignore(existing, features) {
+/** A feature's `.gitignore` lines, under a heading naming it — so a reader can tell why `.wrangler/` is there. */ function appendGitignore(existing, features) {
     const additions = features.filter((feature)=>feature.gitignore?.length);
     if (additions.length === 0) return existing;
     const blocks = additions.map((feature)=>`\n# ${feature.id}\n${feature.gitignore.join('\n')}\n`);
     return existing + blocks.join('');
 }
 /**
- * Turns answers into the exact set of files to write, without touching the target directory — the
- * decisions and the I/O are separated so the whole matrix of answers can be asserted on in a test, and
- * so `--dry-run` is the same code path minus the last step.
+ * Turns answers into the exact set of files to write, without touching the target directory. Separating the
+ * decisions from the I/O is what lets a test assert on the whole matrix of answers, and makes `--dry-run` the
+ * same code path minus the last step.
  */ function plan_plan(answers, pm) {
-    const features = selectFeatures(answers);
-    const tokens = tokensFor(answers, pm);
+    const features = selectFeatures(answers, pm);
+    const tokens = tokensFor(answers, features, pm);
     const raw = readTemplateDir(join(TEMPLATES_DIR, 'base'));
     for (const feature of features){
         for (const overlay of feature.overlays ?? []){
@@ -713,7 +762,9 @@ function readTemplateDir(dir) {
     const gitignore = files.get('.gitignore');
     if (gitignore) files.set('.gitignore', appendGitignore(gitignore, features));
     files.set('package.json', buildPackageJson(answers, features, pm));
-    if (pm.name === 'pnpm') files.set('pnpm-workspace.yaml', buildPnpmSettings(features));
+    // Only for pnpm, and only when a feature brought an install script to answer for — see `buildPnpmSettings`.
+    const pnpmSettings = pm.name === 'pnpm' ? buildPnpmSettings(features) : null;
+    if (pnpmSettings) files.set('pnpm-workspace.yaml', pnpmSettings);
     return {
         // Sorted, so both the write order and a test's snapshot are stable.
         files: new Map([
@@ -747,6 +798,12 @@ const RUN = {
     yarn: 'yarn',
     bun: 'bun'
 };
+const DLX = {
+    npm: 'npx',
+    pnpm: 'pnpm dlx',
+    yarn: 'yarn dlx',
+    bun: 'bunx'
+};
 function isKnown(name) {
     return PACKAGE_MANAGERS.includes(name);
 }
@@ -755,15 +812,14 @@ function packageManager(name, version) {
         name,
         version,
         install: INSTALL[name],
-        run: RUN[name]
+        run: RUN[name],
+        dlx: DLX[name]
     };
 }
 /**
- * Which package manager invoked us. Every one of them sets `npm_config_user_agent` for the process it
- * spawns — `pnpm/11.9.0 npm/? node/v22.14.0 darwin arm64` — so `pnpm create @rshono` scaffolds a pnpm
- * project without asking, and the exact version comes along for the `packageManager` field.
- *
- * Falls back to npm, which is also what a bare `node bin/create-rshono.mjs` gets.
+ * Which package manager invoked us. All four set `npm_config_user_agent` on the process they spawn — `pnpm/11.9.0
+ * npm/? node/v22.14.0 darwin arm64` — so `pnx @rshono/create` scaffolds a pnpm project without asking, exact
+ * version included. Falls back to npm, which is also what a bare `node bin/create-rshono.mjs` gets.
  */ function detectPackageManager(userAgent = process.env.npm_config_user_agent) {
     const [spec] = (userAgent ?? '').split(' ');
     const [name, version] = (spec ?? '').split('/');
@@ -771,18 +827,11 @@ function packageManager(name, version) {
     return packageManager('npm');
 }
 /**
- * Runs the install, streaming its output. `shell: true` on Windows because npm, pnpm and yarn are all
- * `.cmd` shims there, which `spawn` cannot execute directly — and with a shell involved the arguments
- * are all fixed strings from the tables above, never anything the user typed.
+ * Runs the install, streaming its output. `shell: true` on Windows, where npm, pnpm and yarn are `.cmd` shims
+ * `spawn` cannot execute directly — safe because every argument is a fixed string from the tables above.
  */ function runInstall(pm, cwd) {
     return run(pm, pm.install, cwd);
 }
-/** `<pm> run <script>` — the one form every package manager accepts, Yarn v1 included. */ function runScript(pm, script, cwd) {
-    return run(pm, [
-        'run',
-        script
-    ], cwd);
-}
 function run(pm, args, cwd) {
     const result = spawnSync(pm.name, args, {
         cwd,
@@ -795,10 +844,7 @@ function run(pm, args, cwd) {
 ;// CONCATENATED MODULE: ./src/write.ts
 
 
-/**
- * Files that do not make a directory "occupied". A user who ran `git init` or opened the folder in an
- * editor before scaffolding has not put anything in it that we would overwrite.
- */ const IGNORED_ENTRIES = new Set([
+/** Files that do not make a directory "occupied": a `git init` or an editor has put nothing there to overwrite. */ const IGNORED_ENTRIES = new Set([
     '.git',
     '.DS_Store',
     '.idea',
@@ -806,12 +852,9 @@ function run(pm, args, cwd) {
     'Thumbs.db'
 ]);
 /**
- * What is already at the target path, which is what decides whether scaffolding into it is safe: the
- * entries already there, ignoring the ones a fresh clone or an editor leaves behind.
- *
- * A path that does not exist yet is no conflict. A path that exists and is *not* a directory is not
- * something `--force` should be able to write into, so it throws rather than reporting an empty list —
- * otherwise `create-rshono README.md` gets as far as `mkdir` before failing on a raw ENOTDIR.
+ * What is already at the target path, ignoring the entries a fresh clone or an editor leaves behind — which is
+ * what decides whether scaffolding into it is safe. A path that does not exist yet is no conflict; one that
+ * exists and is not a directory throws, since `--force` should not write into it either.
  */ function conflictingEntries(dir) {
     const stats = statSync(dir, {
         throwIfNoEntry: false
@@ -821,8 +864,8 @@ function run(pm, args, cwd) {
     return readdirSync(dir).filter((entry)=>!IGNORED_ENTRIES.has(entry));
 }
 /**
- * Writes the plan. Directories are created as needed, and files are written with the plan's own
- * ordering so a failure part-way through leaves something a person can make sense of.
+ * Writes the plan, creating directories as needed and keeping the plan's own ordering — so a failure part-way
+ * through leaves something a person can make sense of.
  */ function writePlan(plan, targetDir) {
     mkdirSync(targetDir, {
         recursive: true