@oselvar/sveltekit-add-worker-exports 2.2.0 → 2.2.2

package/README.md

@@ -4,7 +4,7 @@ A Vite plugin that makes any class-based Cloudflare Worker export (Durable Objec
 
 Works with **SvelteKit 2 and SvelteKit 3** (see [`example/`](example) and [`example-v3/`](example-v3)).
 
-The examples below use SvelteKit 2's `platform.env`. SvelteKit 3's `adapter-cloudflare` (8.0.0-next.7 and later) no longer provides `event.platform`: read bindings with `import { env } from 'cloudflare:workers'` instead, as [`example-v3/`](example-v3) does. The plugin's dev-registry wiring works the same either way.
+The examples below use SvelteKit 2's `platform.env`. SvelteKit 3's `adapter-cloudflare` (8.x) no longer provides `event.platform`: read bindings with `import { env } from 'cloudflare:workers'` instead, as [`example-v3/`](example-v3) does. The plugin's dev-registry wiring works the same either way.
 
 **Build mode:** SvelteKit's `adapter-cloudflare` generates `_worker.js` with only a default export (the fetch handler). Cloudflare Workers requires class-based bindings (Durable Objects, Workflows, `WorkerEntrypoint`, etc.) to be **named exports**, and non-fetch handlers (`scheduled`, `queue`, `email`, …) to be **methods on the default export**. This plugin post-processes the build output to merge both kinds onto SvelteKit's worker.
 
@@ -63,18 +63,48 @@ Point `adapter-cloudflare`'s platform proxy at the generated `.platform-proxy-wr
 ```javascript
 // svelte.config.js
 import adapter from '@sveltejs/adapter-cloudflare';
+import { fileURLToPath } from 'node:url';
 
 export default {
   kit: {
     adapter: adapter({
       platformProxy: {
-        configPath: '.platform-proxy-wrangler.jsonc'
+        configPath: '.platform-proxy-wrangler.jsonc',
+        persist: { path: fileURLToPath(new URL('.wrangler/state', import.meta.url)) }
       }
     })
   }
 };
 ```
 
+> [!IMPORTANT]
+> **Always set `persist.path` to an absolute path**, as above. Leaving `persist` out is not enough: the default path is relative too. With wrangler 4.129 and later, every Workflow `create()` call in `vite dev` then fails with `Failed to wait for persisted workflow instance '…' deletion`, because miniflare rejects relative persist paths for Workflows.
+
+On SvelteKit 3, which no longer reads `svelte.config.js`, pass the same options to `sveltekit()` in `vite.config.ts`:
+
+```typescript
+// vite.config.ts (SvelteKit 3)
+import { sveltekit } from '@sveltejs/kit/vite';
+import adapter from '@sveltejs/adapter-cloudflare';
+import { addWorkerExports } from '@oselvar/sveltekit-add-worker-exports';
+import { defineConfig } from 'vite';
+import { fileURLToPath } from 'node:url';
+
+export default defineConfig({
+  plugins: [
+    await sveltekit({
+      adapter: adapter({
+        platformProxy: {
+          configPath: '.platform-proxy-wrangler.jsonc',
+          persist: { path: fileURLToPath(new URL('.wrangler/state', import.meta.url)) }
+        }
+      })
+    }),
+    addWorkerExports({ entryPoint: 'src/lib/server/index.ts' })
+  ]
+});
+```
+
 The plugin auto-discovers your `wrangler.jsonc` (or `wrangler.toml`) and reads bindings, workflows, migrations, and compatibility settings from it. It overrides only the `main` entry point to point at your source entry.
 
 ### Calling Workflows
@@ -93,6 +123,8 @@ export const POST: RequestHandler = async ({ params, request, platform }) => {
 
 The sidecar runs the real `WorkflowEntrypoint` class; calls reach it via the `script_name` rewrite in the platform-proxy config. This requires `wrangler >= 4.98.0` ([cloudflare/workers-sdk#13863](https://github.com/cloudflare/workers-sdk/pull/13863)).
 
+If `create()` fails in dev with `Failed to wait for persisted workflow instance '…' deletion`, your `platformProxy.persist.path` is missing or relative. Set it to an absolute path, as shown in [Usage](#usage).
+
 ### Testing the production build locally
 
 `vite dev` exercises your code via the wrangler-dev sidecar; it does *not* exercise the merged `_worker.js`. To verify the production wiring (named class exports + SvelteKit routes in the same worker), run wrangler against the build output:
@@ -116,6 +148,16 @@ A handy shortcut is to add a `preview` script to `package.json`:
 
 > Note: `vite preview` is *not* suitable here — it only serves static assets and cannot run Durable Objects. Always use `wrangler dev` to preview the production worker.
 
+### Wrangler environments
+
+Set `CLOUDFLARE_ENV` to run dev against one of the `env` blocks in your wrangler config:
+
+```bash
+CLOUDFLARE_ENV=staging pnpm dev
+```
+
+The sidecar then behaves like `wrangler dev --env staging`: it uses `env.staging`'s bindings and `vars`, loads `.env.staging` / `.env.staging.local` (or `.dev.vars.staging`) on top of `.env` / `.env.local`, and registers as `<name>-dev-worker-staging`. As with wrangler, values in `.env` files override `vars`.
+
 ## Scheduled, queue, email, tail handlers
 
 Cloudflare invokes non-fetch handlers (`scheduled`, `queue`, `email`, `tail`, `trace`) as methods on the worker's default export, not as named exports. Put them on the `default` export of your entry point and the plugin merges them onto the production worker's default alongside SvelteKit's fetch handler:

package/dist/index.d.ts

@@ -20,9 +20,9 @@
  *
  * @see https://github.com/sveltejs/kit/issues/1712
  */
-import { type ModuleRule } from 'miniflare';
 import type { Plugin } from 'vite';
-export { createModuleRulesPlugin, toModuleRule, WRANGLER_DEFAULT_MODULE_RULES, type WranglerRule } from './moduleRules.js';
+import { type ModuleRule } from './moduleRules.js';
+export { createModuleRulesPlugin, toModuleRule, WRANGLER_DEFAULT_MODULE_RULES, type ModuleRule, type ModuleRuleType, type WranglerRule } from './moduleRules.js';
 /**
  * Parses a wrangler config file. Picks the parser by extension:
  * `.toml` uses smol-toml; everything else (`.jsonc`, `.json`, or no
@@ -146,3 +146,22 @@ export declare function deriveDevWorkerConfig(baseConfig: any, options: Pick<Add
  * absolute path written.
  */
 export declare function writeDevWorkerConfig(options: AddWorkerExportsOptions, outPath?: string): Promise<string>;
+export type NodeJSCompatMode = 'als' | 'v1' | 'v2' | null;
+/**
+ * Resolves the Node.js compat mode the way wrangler's own `getNodeCompat`
+ * does (workers-utils `node-compat.ts` / `compatibility-date.ts`).
+ *
+ * The dev sidecar passes it to `unstable_startWorker` as the
+ * `build.nodejsCompatMode` hook. wrangler before 4.113 doesn't derive the
+ * mode itself and falls back to the legacy nodejs compat plugin, which warns
+ * about `node:*` imports even with `nodejs_compat` enabled.
+ *
+ * This used to call miniflare's `getNodeCompat`, but miniflare
+ * 5.20261103.0-beta (shipped with wrangler 4.157+) no longer exports it, and
+ * importing a missing named export from miniflare (a CommonJS module) is a
+ * SyntaxError that stops the plugin from loading. miniflare 4's copy also
+ * predates the default-on date.
+ *
+ * Exported for tests.
+ */
+export declare function getNodejsCompatMode(compatibilityDate?: string, compatibilityFlags?: readonly string[]): NodeJSCompatMode;

package/dist/index.js

@@ -28,7 +28,6 @@ import { connect } from 'node:net';
 import { homedir } from 'node:os';
 import { join, resolve } from 'node:path';
 import { parse as parseJsonc } from 'jsonc-parser';
-import { getNodeCompat } from 'miniflare';
 import { parse as parseToml } from 'smol-toml';
 import { createModuleRulesPlugin, toModuleRule } from './moduleRules.js';
 export { createModuleRulesPlugin, toModuleRule, WRANGLER_DEFAULT_MODULE_RULES } from './moduleRules.js';
@@ -417,6 +416,14 @@ function devPlugins(options) {
                 await removeDeadRegistryEntry(registryPath, registeredSidecarName);
                 worker = await unstable_startWorker({
                     config: tempConfigPath,
+                    // Wrangler falls back to CLOUDFLARE_ENV when resolving the
+                    // config (and the sidecar's name), but not when choosing which
+                    // `.env` / `.dev.vars` files to load: without `env`, only `.env`
+                    // and `.env.local` are read, and they override the env's `vars`.
+                    // Passing it adds `.env.<env>` / `.dev.vars.<env>`, matching
+                    // `wrangler dev --env <env>`. See
+                    // https://github.com/oselvar/sveltekit-add-worker-exports/issues/11
+                    env: process.env.CLOUDFLARE_ENV,
                     // `testScheduled` mounts a `/__scheduled` endpoint on the sidecar
                     // so cron handlers can be invoked manually in dev — wrangler dev
                     // never auto-fires crons. Curl
@@ -476,12 +483,39 @@ async function exists(path) {
         return false;
     }
 }
+/** From this compatibility date, `nodejs_compat` is on unless `no_nodejs_compat` is set. */
+const NODEJS_COMPAT_DEFAULT_ON_DATE = '2026-08-04';
+/** From this compatibility date, `nodejs_compat` means v2. */
+const NODEJS_COMPAT_V2_SWITCH_OVER_DATE = '2024-09-23';
 /**
- * wrangler's `unstable_startWorker` does not derive this from the config
- * flags automatically — without it, wrangler falls back to the legacy
- * nodejs compat plugin and warns about `node:*` imports even when
- * `nodejs_compat` is enabled.
+ * Resolves the Node.js compat mode the way wrangler's own `getNodeCompat`
+ * does (workers-utils `node-compat.ts` / `compatibility-date.ts`).
+ *
+ * The dev sidecar passes it to `unstable_startWorker` as the
+ * `build.nodejsCompatMode` hook. wrangler before 4.113 doesn't derive the
+ * mode itself and falls back to the legacy nodejs compat plugin, which warns
+ * about `node:*` imports even with `nodejs_compat` enabled.
+ *
+ * This used to call miniflare's `getNodeCompat`, but miniflare
+ * 5.20261103.0-beta (shipped with wrangler 4.157+) no longer exports it, and
+ * importing a missing named export from miniflare (a CommonJS module) is a
+ * SyntaxError that stops the plugin from loading. miniflare 4's copy also
+ * predates the default-on date.
+ *
+ * Exported for tests.
  */
-function getNodejsCompatMode(compatibilityDate, compatibilityFlags = []) {
-    return getNodeCompat(compatibilityDate, [...compatibilityFlags]).mode;
+export function getNodejsCompatMode(compatibilityDate = '2000-01-01', compatibilityFlags = []) {
+    const has = (flag) => compatibilityFlags.includes(flag);
+    const isDefaultOn = compatibilityDate >= NODEJS_COMPAT_DEFAULT_ON_DATE;
+    const isV1Enabled = has('nodejs_compat') || (isDefaultOn && !has('no_nodejs_compat'));
+    const isV2Enabled = has('nodejs_compat_v2') ||
+        (!has('no_nodejs_compat_v2') &&
+            (isDefaultOn || (isV1Enabled && compatibilityDate >= NODEJS_COMPAT_V2_SWITCH_OVER_DATE)));
+    if (isV2Enabled)
+        return 'v2';
+    if (isV1Enabled)
+        return 'v1';
+    if (has('nodejs_als'))
+        return 'als';
+    return null;
 }

package/dist/moduleRules.d.ts

@@ -21,7 +21,19 @@
  * (`**\/*.sql`, `**\/*.txt`) behave identically under both.
  */
 import type { Plugin as EsbuildPlugin } from 'esbuild';
-import { type ModuleRule, type ModuleRuleType } from 'miniflare';
+/**
+ * Declared here rather than imported: miniflare 4 calls these `ModuleRuleType`
+ * / `ModuleRule`, miniflare 5 renamed them to `V4ModuleRuleType` /
+ * `V4ModuleRule`. The shape is identical in both, so this type-checks against
+ * whichever miniflare the consumer has.
+ */
+export type ModuleRuleType = 'ESModule' | 'CommonJS' | 'Text' | 'Data' | 'CompiledWasm' | 'PythonModule' | 'PythonRequirement';
+/** A module rule in miniflare's shape. */
+export interface ModuleRule {
+    type: ModuleRuleType;
+    include: string[];
+    fallthrough?: boolean;
+}
 /** A module rule as it appears in wrangler config (miniflare uses `include`). */
 export interface WranglerRule {
     type: ModuleRuleType;

package/dist/moduleRules.js

@@ -53,6 +53,8 @@ export function createModuleRulesPlugin(userRules) {
     // JS rules are dropped from the match loop — esbuild's default handling is
     // exactly their meaning — but they still participate in fallthrough
     // finalisation above, like in wrangler.
+    // The cast pins `type` to our `ModuleRuleType`: miniflare 4 declares it as
+    // a `z.infer<…>` that TypeScript 7 doesn't narrow to the string union.
     const kept = compileModuleRules(allRules).filter((rule) => !isJavaScriptRuleType(rule.type));
     // Recompute which rules `compileModuleRules` dropped, so files matching
     // only a shadowed rule get wrangler's error instead of esbuild's opaque

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@oselvar/sveltekit-add-worker-exports",
-	"version": "2.2.0",
+	"version": "2.2.2",
 	"description": "Vite plugin that adds Durable Object and Workflow exports to SvelteKit Cloudflare workers",
 	"type": "module",
 	"publishConfig": {
@@ -40,16 +40,16 @@
 		"wrangler": ">=4"
 	},
 	"devDependencies": {
-		"@release-it/conventional-changelog": "^11.0.1",
-		"@sveltejs/kit": "^2.70.3",
-		"@types/node": "^26.6.2",
+		"@release-it/conventional-changelog": "^12.0.2",
+		"@sveltejs/kit": "^2.70.4",
+		"@types/node": "^26.6.6",
 		"esbuild": "^0.28.2",
-		"miniflare": "^4.20260730.0",
-		"release-it": "^20.2.1",
+		"miniflare": "5.20261109.0-beta",
+		"release-it": "^21.1.2",
 		"typescript": "^7.0.2",
-		"vite": "^8.3.0",
-		"vitest": "^4.1.11",
-		"wrangler": "^4.136.2"
+		"vite": "^8.3.7",
+		"vitest": "^5.1.0",
+		"wrangler": "^4.159.0"
 	},
 	"scripts": {
 		"build": "tsc",
@@ -68,6 +68,6 @@
 	},
 	"dependencies": {
 		"jsonc-parser": "^3.3.1",
-		"smol-toml": "^1.8.0"
+		"smol-toml": "^1.9.1"
 	}
 }