@tollwyn/baukasten 2.0.0 → 2.0.1

package/README.md

@@ -271,12 +271,23 @@ Its pages, mails, legal texts, variables and migrations stay as they were: a pro
 variable, and its database stays as it is. A product on 1.x keeps running as it is; it takes 2.0 in
 one change, a web app and a Shopify app alike:
 
-1. `npm install --save-exact @tollwyn/baukasten@<version>`, a version from 2.0.0 on, and
-   `npm install --save-dev @sveltejs/kit@3 @sveltejs/adapter-node@6`, with what SvelteKit 3 needs:
-   Vite 8, `@sveltejs/vite-plugin-svelte` 7, TypeScript 6 and Svelte from 5.57.1 on.
+1. One command, with a version from 2.0.0 on:
+
+   ```sh
+   npm install --save-exact @tollwyn/baukasten@<version> @sveltejs/kit@3 @sveltejs/adapter-node@6
+   ```
+
+   The baukasten and adapter-node take SvelteKit as a peer, so npm can move the three only
+   together; it keeps each package in the section of `package.json` where the product has it. A
+   product below what SvelteKit 3 needs, Vite 8, `@sveltejs/vite-plugin-svelte` 7, TypeScript 6 and
+   Svelte from 5.57.1 on, names those in the same command, as it does any other package of its own
+   that npm's ERESOLVE names. Coming from `@sveltejs/vite-plugin-svelte` 6, npm resolves it from a
+   fresh lockfile: delete `package-lock.json` and `node_modules`, then run the command. The old
+   lockfile still holds `@sveltejs/vite-plugin-svelte-inspector`, whose peer range ends at Vite 7.
 2. The product's own code after the guide of SvelteKit,
-   https://svelte.dev/docs/kit/migrating-to-sveltekit-3 (`npx sv migrate sveltekit-3` does much of
-   it). What a product of the baukasten meets there:
+   https://svelte.dev/docs/kit/migrating-to-sveltekit-3
+   (`npx sv migrate sveltekit-3 --tasks all --confirm --no-install --no-git-check` does much of it;
+   without `--tasks` it asks which tasks to run). What a product of the baukasten meets there:
    - `$lib` becomes `#lib`, imported with the extension of the module (`#lib/texts.js`), and
      `package.json` maps `"#lib/*": "./src/lib/*"` in `imports`.
    - `tsconfig.json` extends `$app/tsconfig` and names its own `include`; a `types` of its own names
@@ -289,7 +300,8 @@ one change, a web app and a Shopify app alike:
 3. `npx --no-install baukasten-stubs` writes the stubs of 2.0, `npx --no-install baukasten-stubs
    shopify` those of a Shopify app. The product's own `src/lib/server/handle.ts` takes `Handle`
    from `@sveltejs/kit/hooks`.
-4. An override of `cookie` goes, where the product has one: SvelteKit 3 brings `cookie` 2, which
+4. An override of `cookie` goes, where the product has one, and a plain `npm install` follows: until
+   then the override holds `cookie` where it was. SvelteKit 3 brings `cookie` 2, which
    GHSA-pxg6-pf52-xh8x does not reach.
 5. `npx --no-install baukasten-check`, then the gate of the product.
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@tollwyn/baukasten",
-	"version": "2.0.0",
+	"version": "2.0.1",
 	"description": "What every product built on this kit shares: configuration, log and server, database with two-layer migrations, health, accounts with sessions and API keys, limits, mail, payment through Stripe, the numbers for sales, the frame and pages, the stubs that hang them into a product and the check of a product, and the tools to test one, its connection test among them; and for a Shopify app its installation with tokens, the frame of the admin, its webhooks, its plan through the Partner API and its privacy text.",
 	"license": "UNLICENSED",
 	"type": "module",