@oselvar/sveltekit-add-worker-exports 2.1.0 → 2.1.2

package/README.md

@@ -2,6 +2,8 @@
 
 A Vite plugin that makes any class-based Cloudflare Worker export (Durable Objects, Workflows, `WorkerEntrypoint` RPC, voice agents, …) and any non-fetch handler (`scheduled`, `queue`, `email`, `tail`, `trace`) work with SvelteKit on Cloudflare, in both dev and production.
 
+Works with **SvelteKit 2 and SvelteKit 3** (see [`example/`](example) and [`example-v3/`](example-v3)).
+
 **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.
 
 **Dev mode:** `getPlatformProxy` (used by `adapter-cloudflare` in dev) can't run internal Durable Objects, Workflows, or other class-based bindings. This plugin starts a separate wrangler dev server that runs the real worker with hot-reload. SvelteKit `+server.ts` handlers call bindings through `platform.env.MY_BINDING.<rpc>()` as usual — the plugin rewrites those bindings to point at the sidecar via wrangler's dev registry, so cross-worker calls Just Work. WebSocket clients in dev connect to the sidecar directly on a separate port — see [WebSockets](#websockets) below. The sidecar also exposes `/__scheduled` so `scheduled` handlers can be fired manually in dev — see [Scheduled, queue, email, tail handlers](#scheduled-queue-email-tail-handlers).
@@ -215,6 +217,49 @@ declare global {
 }
 ```
 
+## Importing non-JS modules (`.sql`, `.txt`, …)
+
+Wrangler lets workers import non-JavaScript files as modules via
+[module rules](https://developers.cloudflare.com/workers/wrangler/configuration/#bundling):
+`Text` rules import as a `string`, `Data` rules as an `ArrayBuffer`. Wrangler
+applies a set of default rules even without any config — `**/*.txt`,
+`**/*.html`, and `**/*.sql` as `Text`, `**/*.bin` as `Data`.
+
+The plugin honors the same contract in both modes: the dev sidecar is bundled
+by wrangler itself, and the build-mode esbuild pass translates the `rules`
+from your wrangler config (plus wrangler's defaults) into esbuild loaders and
+inlines the file contents into `_extra_exports.js`.
+
+This makes [Drizzle's durable-sqlite migrations](https://orm.drizzle.team/docs/sqlite/connect-cloudflare-do)
+work out of the box ([#8](https://github.com/oselvar/sveltekit-add-worker-exports/issues/8)):
+the generated `drizzle/migrations.js` imports `.sql` files, which wrangler's
+default rules cover — no `rules` config needed. Custom extensions need a rule:
+
+```jsonc
+// wrangler.jsonc
+"rules": [{ "type": "Text", "globs": ["**/*.graphql"], "fallthrough": true }]
+```
+
+And a type declaration so TypeScript accepts the import:
+
+```typescript
+// src/app.d.ts
+declare module '*.graphql' {
+	const contents: string;
+	export default contents;
+}
+```
+
+Caveats:
+
+- `CompiledWasm`, `PythonModule`, and `PythonRequirement` rules can't be
+  inlined into the single-file production bundle; importing a file matched by
+  one fails the build with an explanatory error.
+- Glob matching in build mode uses miniflare's matcher (`globstar` semantics,
+  matched against resolved file paths) while wrangler's dev bundler matches
+  import specifiers with non-`globstar` semantics. The canonical shapes
+  (`**/*.ext`) behave identically under both; exotic globs may differ.
+
 ## Options
 
 | Option | Type | Required | Default | Description |
@@ -228,9 +273,9 @@ declare global {
 
 ### Build mode
 
-The plugin runs in the `closeBundle` hook (after SvelteKit's adapter has generated `_worker.js`):
+The plugin runs after SvelteKit's adapter has generated `_worker.js`. SvelteKit v2 runs the adapter in Vite's `closeBundle` hook, while SvelteKit v3 moved it into the newer `buildApp` hook (which runs *after* every `closeBundle`). The plugin registers its patch step on **both** hooks (idempotent), so whichever one runs after the adapter does the work:
 
-1. Bundles your `entryPoint` with esbuild into `_extra_exports.js`
+1. Bundles your `entryPoint` with esbuild into `_extra_exports.js`, applying the wrangler config's module `rules` (plus wrangler's defaults) so `.sql`/`.txt`-style imports are inlined — see [Importing non-JS modules](#importing-non-js-modules-sql-txt-)
 2. Renames the original `_worker.js` to `_sveltekit_worker.js`
 3. Creates a new `_worker.js` that re-exports the named exports and merges the entry's `default` handlers (`scheduled`, `queue`, `email`, …) onto the SvelteKit default:
 
@@ -242,7 +287,9 @@ const { fetch: _ignored, ...extraHandlers } = extra.default ?? {};
 export default { ...sveltekitWorker, ...extraHandlers };
 ```
 
-The operation is idempotent -- if `_sveltekit_worker.js` already exists, the plugin skips.
+4. Appends its own outputs (`_sveltekit_worker.js`, `_extra_exports.js`, and their `.map` sidecars) to the adapter's `.assetsignore`. These are server-side / Durable Object bundles and source maps; the adapter's generated `.assetsignore` only excludes its own outputs, so without this Cloudflare would serve them as public static assets (the maps' `sourcesContent` would expose your original TypeScript). `.assetsignore` only controls public asset serving — the files stay on disk, so wrangler still bundles the worker and uploads its source maps.
+
+The operation is idempotent -- if `_sveltekit_worker.js` already exists, the second hook skips. Tested against SvelteKit v2 (see [`example/`](example)) and v3 (see [`example-v3/`](example-v3)).
 
 ### Dev mode
 

package/dist/index.d.ts

@@ -20,7 +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';
 /**
  * Parses a wrangler config file. Picks the parser by extension:
  * `.toml` uses smol-toml; everything else (`.jsonc`, `.json`, or no
@@ -29,6 +31,23 @@ import type { Plugin } from 'vite';
  * Exported for tests; the dev plugin uses it via the configureServer hook.
  */
 export declare function parseWranglerConfig(path: string, contents: string): unknown;
+/**
+ * The build outputs this plugin writes into the adapter's output dir. They are
+ * server-side / Durable Object bundles and their source maps — never meant to
+ * be downloadable. adapter-cloudflare's generated `.assetsignore` only excludes
+ * its own outputs (`_worker.js`, `_routes.json`, `_headers`, `_redirects`), so
+ * without this Cloudflare would serve these as public static assets, leaking
+ * the bundled code and (via the maps' `sourcesContent`) the original
+ * TypeScript. See https://github.com/oselvar/sveltekit-add-worker-exports/issues/4
+ */
+export declare const PLUGIN_ASSETS_IGNORE_ENTRIES: string[];
+/**
+ * Returns `.assetsignore` content with `entries` appended, skipping any that
+ * are already present (trim-compared). Preserves existing lines and order,
+ * normalises to a trailing newline. Idempotent — `.assetsignore` controls only
+ * public asset serving, so the listed files stay on disk for wrangler to bundle.
+ */
+export declare function mergeAssetsIgnore(existing: string, entries: string[]): string;
 export interface AddWorkerExportsOptions {
     /** File that exports Durable Object and/or Workflow classes */
     entryPoint: string;
@@ -65,3 +84,26 @@ export interface AddWorkerExportsOptions {
  * ```
  */
 export declare function addWorkerExports(options: AddWorkerExportsOptions): Plugin[];
+/**
+ * Patches the adapter-generated `_worker.js`: bundles the named exports into
+ * `_extra_exports.js`, renames the original worker to `_sveltekit_worker.js`,
+ * and writes a merged `_worker.js`. Idempotent — safe to call from more than
+ * one Vite hook; the first call that finds `_worker.js` does the work, later
+ * calls see `_sveltekit_worker.js` and return.
+ *
+ * Returns `true` if it patched (or had already patched), `false` if the
+ * adapter hasn't written `_worker.js` yet.
+ */
+/**
+ * Reads the module `rules` from the wrangler config (auto-discovered, or
+ * `options.wranglerConfig` when set) for the build-mode bundle. Wrangler
+ * resolves `CLOUDFLARE_ENV` and per-env `rules` inheritance itself.
+ *
+ * When no config is found by auto-discovery, wrangler returns an empty
+ * config, so this yields no user rules (wrangler's default rules still
+ * apply). A missing `wranglerConfig` path, a syntax error, or a validation
+ * error throws and fails the build — the same config would fail
+ * `wrangler dev`/`deploy`, so surfacing it here is strictly earlier, not a
+ * new requirement.
+ */
+export declare function readModuleRules(options: AddWorkerExportsOptions): Promise<ModuleRule[]>;

package/dist/index.js

@@ -29,6 +29,8 @@ 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';
 /**
  * Parses a wrangler config file. Picks the parser by extension:
  * `.toml` uses smol-toml; everything else (`.jsonc`, `.json`, or no
@@ -40,6 +42,37 @@ export function parseWranglerConfig(path, contents) {
     return path.endsWith('.toml') ? parseToml(contents) : parseJsonc(contents);
 }
 const DEFAULT_DEV_PORT = 8787;
+/**
+ * The build outputs this plugin writes into the adapter's output dir. They are
+ * server-side / Durable Object bundles and their source maps — never meant to
+ * be downloadable. adapter-cloudflare's generated `.assetsignore` only excludes
+ * its own outputs (`_worker.js`, `_routes.json`, `_headers`, `_redirects`), so
+ * without this Cloudflare would serve these as public static assets, leaking
+ * the bundled code and (via the maps' `sourcesContent`) the original
+ * TypeScript. See https://github.com/oselvar/sveltekit-add-worker-exports/issues/4
+ */
+export const PLUGIN_ASSETS_IGNORE_ENTRIES = [
+    '_sveltekit_worker.js',
+    '_sveltekit_worker.js.map',
+    '_extra_exports.js',
+    '_extra_exports.js.map'
+];
+/**
+ * Returns `.assetsignore` content with `entries` appended, skipping any that
+ * are already present (trim-compared). Preserves existing lines and order,
+ * normalises to a trailing newline. Idempotent — `.assetsignore` controls only
+ * public asset serving, so the listed files stay on disk for wrangler to bundle.
+ */
+export function mergeAssetsIgnore(existing, entries) {
+    const lines = existing.split('\n');
+    const present = new Set(lines.map((l) => l.trim()));
+    const additions = entries.filter((e) => !present.has(e.trim()));
+    // Drop trailing blank lines so we append cleanly, then re-add one newline.
+    while (lines.length > 0 && lines[lines.length - 1].trim() === '') {
+        lines.pop();
+    }
+    return [...lines, ...additions].join('\n') + '\n';
+}
 /**
  * Mirrors wrangler's internal getRegistryPath() — wrangler doesn't export it.
  * Workers register themselves under this path so cross-worker `script_name`
@@ -76,66 +109,126 @@ function getWranglerRegistryPath() {
 export function addWorkerExports(options) {
     return [buildPlugin(options), devPlugin(options)];
 }
+/**
+ * Patches the adapter-generated `_worker.js`: bundles the named exports into
+ * `_extra_exports.js`, renames the original worker to `_sveltekit_worker.js`,
+ * and writes a merged `_worker.js`. Idempotent — safe to call from more than
+ * one Vite hook; the first call that finds `_worker.js` does the work, later
+ * calls see `_sveltekit_worker.js` and return.
+ *
+ * Returns `true` if it patched (or had already patched), `false` if the
+ * adapter hasn't written `_worker.js` yet.
+ */
+/**
+ * Reads the module `rules` from the wrangler config (auto-discovered, or
+ * `options.wranglerConfig` when set) for the build-mode bundle. Wrangler
+ * resolves `CLOUDFLARE_ENV` and per-env `rules` inheritance itself.
+ *
+ * When no config is found by auto-discovery, wrangler returns an empty
+ * config, so this yields no user rules (wrangler's default rules still
+ * apply). A missing `wranglerConfig` path, a syntax error, or a validation
+ * error throws and fails the build — the same config would fail
+ * `wrangler dev`/`deploy`, so surfacing it here is strictly earlier, not a
+ * new requirement.
+ */
+export async function readModuleRules(options) {
+    // Dynamic import: loading wrangler's bundle takes ~500ms, and this module
+    // is evaluated on every vite invocation via vite.config.ts. Deferring the
+    // import to the once-per-run call sites (here and the dev plugin's
+    // configureServer) keeps that cost out of vite's config load.
+    const { unstable_readConfig } = await import('wrangler');
+    const config = unstable_readConfig(options.wranglerConfig ? { config: options.wranglerConfig } : {}, { hideWarnings: true });
+    return (config.rules ?? []).map(toModuleRule);
+}
+async function patchWorker(options) {
+    const outputDir = resolve(options.outputDir ?? '.svelte-kit/cloudflare');
+    const workerPath = resolve(outputDir, '_worker.js');
+    const sveltekitPath = resolve(outputDir, '_sveltekit_worker.js');
+    const exportsPath = resolve(outputDir, '_extra_exports.js');
+    // Skip if already patched (idempotent)
+    if (await exists(sveltekitPath)) {
+        return true;
+    }
+    // Skip if the adapter hasn't run yet (e.g. during the SSR build phase, or
+    // before SvelteKit v3's `buildApp` hook runs the adapter)
+    if (!(await exists(workerPath))) {
+        return false;
+    }
+    // Bundle the named exports.
+    //
+    // `conditions: ['workerd', 'worker', 'browser']` is the Cloudflare-
+    // recommended set for bundlers targeting Workers — it picks the
+    // workerd-specific or browser-shimmed variants of packages over
+    // their Node variants (e.g. nanoid's webcrypto-via-`globalThis.crypto`
+    // browser build instead of the `node:crypto`-importing main build).
+    //
+    // Node built-ins are externalised so transitive deps that do
+    // `require('path')` or `import 'node:async_hooks'` survive bundling;
+    // the Workers runtime resolves them when `nodejs_compat` is enabled
+    // in wrangler.jsonc.
+    //
+    // The module-rules plugin applies the wrangler config's `rules` (plus
+    // wrangler's defaults, e.g. `.sql`/`.txt` as Text), matching what
+    // wrangler's own bundler does for the dev sidecar. See moduleRules.ts.
+    await build({
+        entryPoints: [options.entryPoint],
+        bundle: true,
+        format: 'esm',
+        sourcemap: true,
+        target: 'esnext',
+        conditions: ['workerd', 'worker', 'browser'],
+        external: ['cloudflare:*', ...NODE_BUILTINS, ...NODE_BUILTINS.map((m) => `node:${m}`)],
+        plugins: [createModuleRulesPlugin(await readModuleRules(options))],
+        outfile: exportsPath
+    });
+    // Rename original worker and create merged entry point.
+    //
+    // `export *` re-exports named exports only, so class-based bindings
+    // (DOs, Workflows, WorkerEntrypoint) from `_extra_exports.js` flow
+    // through. Non-fetch handlers (scheduled, queue, email, tail, trace)
+    // live on the user entry's `default` export — Cloudflare invokes
+    // them as methods on the worker's default object, not as named
+    // exports — so we spread them onto the SvelteKit default. `fetch`
+    // is dropped from the user default because SvelteKit owns request
+    // handling in production.
+    await rename(workerPath, sveltekitPath);
+    await writeFile(workerPath, `import sveltekitWorker from './_sveltekit_worker.js';\n` +
+        `import * as extra from './_extra_exports.js';\n` +
+        `export * from './_extra_exports.js';\n` +
+        `const { fetch: _ignored, ...extraHandlers } = extra.default ?? {};\n` +
+        `export default { ...sveltekitWorker, ...extraHandlers };\n`);
+    // Keep this plugin's server bundles and source maps out of the
+    // publicly-served assets. The adapter regenerates `.assetsignore` every
+    // build with only its own outputs; we append ours here, right after
+    // patching, so it survives each deploy regardless of which hook ran the
+    // patch (v2: `closeBundle`, v3: `buildApp`).
+    const assetsIgnorePath = resolve(outputDir, '.assetsignore');
+    const currentIgnore = (await exists(assetsIgnorePath))
+        ? await readFile(assetsIgnorePath, 'utf-8')
+        : '';
+    await writeFile(assetsIgnorePath, mergeAssetsIgnore(currentIgnore, PLUGIN_ASSETS_IGNORE_ENTRIES));
+    return true;
+}
 function buildPlugin(options) {
     return {
         name: 'add-worker-exports',
         apply: 'build',
         enforce: 'post',
+        // SvelteKit v2 runs the Cloudflare adapter inside `closeBundle`; our
+        // `enforce: 'post'` hook then runs after it and sees `_worker.js`.
         async closeBundle() {
-            const outputDir = resolve(options.outputDir ?? '.svelte-kit/cloudflare');
-            const workerPath = resolve(outputDir, '_worker.js');
-            const sveltekitPath = resolve(outputDir, '_sveltekit_worker.js');
-            const exportsPath = resolve(outputDir, '_extra_exports.js');
-            // Skip if already patched (idempotent)
-            if (await exists(sveltekitPath)) {
-                return;
-            }
-            // Skip if the adapter hasn't run yet (e.g. during SSR build phase)
-            if (!(await exists(workerPath))) {
-                return;
+            await patchWorker(options);
+        },
+        // SvelteKit v3 moved the adapter into Vite's `buildApp` hook, which runs
+        // *after* every `closeBundle`. By that point our `closeBundle` has
+        // already run and skipped (no `_worker.js` yet), so we patch here
+        // instead. `order: 'post'` ensures we run after SvelteKit's own
+        // `buildApp` that generates `_worker.js`. Harmless on v2 (idempotent).
+        buildApp: {
+            order: 'post',
+            async handler() {
+                await patchWorker(options);
             }
-            // Bundle the named exports.
-            //
-            // `conditions: ['workerd', 'worker', 'browser']` is the Cloudflare-
-            // recommended set for bundlers targeting Workers — it picks the
-            // workerd-specific or browser-shimmed variants of packages over
-            // their Node variants (e.g. nanoid's webcrypto-via-`globalThis.crypto`
-            // browser build instead of the `node:crypto`-importing main build).
-            //
-            // Node built-ins are externalised so transitive deps that do
-            // `require('path')` or `import 'node:async_hooks'` survive bundling;
-            // the Workers runtime resolves them when `nodejs_compat` is enabled
-            // in wrangler.jsonc.
-            await build({
-                entryPoints: [options.entryPoint],
-                bundle: true,
-                format: 'esm',
-                sourcemap: true,
-                target: 'esnext',
-                conditions: ['workerd', 'worker', 'browser'],
-                external: [
-                    'cloudflare:*',
-                    ...NODE_BUILTINS,
-                    ...NODE_BUILTINS.map((m) => `node:${m}`)
-                ],
-                outfile: exportsPath
-            });
-            // Rename original worker and create merged entry point.
-            //
-            // `export *` re-exports named exports only, so class-based bindings
-            // (DOs, Workflows, WorkerEntrypoint) from `_extra_exports.js` flow
-            // through. Non-fetch handlers (scheduled, queue, email, tail, trace)
-            // live on the user entry's `default` export — Cloudflare invokes
-            // them as methods on the worker's default object, not as named
-            // exports — so we spread them onto the SvelteKit default. `fetch`
-            // is dropped from the user default because SvelteKit owns request
-            // handling in production.
-            await rename(workerPath, sveltekitPath);
-            await writeFile(workerPath, `import sveltekitWorker from './_sveltekit_worker.js';\n` +
-                `import * as extra from './_extra_exports.js';\n` +
-                `export * from './_extra_exports.js';\n` +
-                `const { fetch: _ignored, ...extraHandlers } = extra.default ?? {};\n` +
-                `export default { ...sveltekitWorker, ...extraHandlers };\n`);
         }
     };
 }
@@ -145,6 +238,7 @@ function devPlugin(options) {
     let tempConfigPath = null;
     let proxyConfigPath = null;
     async function readRawConfig() {
+        // Dynamic import — see readModuleRules for why.
         const { unstable_readConfig } = await import('wrangler');
         const parsed = unstable_readConfig(options.wranglerConfig ? { config: options.wranglerConfig } : {});
         const path = parsed.configPath;
@@ -162,6 +256,7 @@ function devPlugin(options) {
             };
         },
         async configureServer(server) {
+            // Dynamic import — see readModuleRules for why.
             const { unstable_startWorker } = await import('wrangler');
             const { path: configPath, contents } = await readRawConfig();
             const baseConfig = parseWranglerConfig(configPath, contents);

package/dist/moduleRules.d.ts

@@ -0,0 +1,46 @@
+/**
+ * Translates wrangler module `rules` into an esbuild plugin so the build-mode
+ * bundle honors the same contract wrangler's own bundler honors in dev.
+ *
+ * Wrangler config rules look like
+ * `{ "type": "Text", "globs": ["**\/*.sql"], "fallthrough": true }` and make
+ * matching imports resolve to the file contents (as a string for `Text`, an
+ * `ArrayBuffer` for `Data`). Wrangler applies them — plus a set of default
+ * rules — whenever it bundles a worker (`wrangler dev`, `wrangler deploy`,
+ * and this plugin's dev sidecar). The build-mode `esbuild.build()` call in
+ * `patchWorker` runs outside wrangler, so without this plugin a `.sql` import
+ * that works in dev fails the production build with "No loader is configured".
+ * See https://github.com/oselvar/sveltekit-add-worker-exports/issues/8
+ *
+ * Wrangler exports none of its rules machinery, but miniflare (already a peer
+ * dependency) exports `compileModuleRules`/`testRegExps` with the same
+ * fallthrough semantics, so only wrangler's default rule list is replicated
+ * here. One divergence: miniflare compiles globs with `globstar: true` and
+ * matches resolved file paths, while wrangler's bundler compiles with
+ * `globstar: false` and matches import specifiers. The canonical shapes
+ * (`**\/*.sql`, `**\/*.txt`) behave identically under both.
+ */
+import type { Plugin as EsbuildPlugin } from 'esbuild';
+import { type ModuleRule, type ModuleRuleType } from 'miniflare';
+/** A module rule as it appears in wrangler config (miniflare uses `include`). */
+export interface WranglerRule {
+    type: ModuleRuleType;
+    globs: string[];
+    fallthrough?: boolean;
+}
+export declare function toModuleRule(rule: WranglerRule): ModuleRule;
+/**
+ * Wrangler's `DEFAULT_MODULE_RULES` (src/deployment-bundle/rules.ts), in
+ * miniflare's shape. Wrangler appends these after user rules everywhere it
+ * bundles, so the plugin does the same — `.sql`, `.txt`, and `.html` imports
+ * work with no `rules` config at all, matching `wrangler dev`.
+ */
+export declare const WRANGLER_DEFAULT_MODULE_RULES: ModuleRule[];
+/**
+ * Builds an esbuild plugin that applies `userRules` followed by wrangler's
+ * default rules, first match wins. Matching honors wrangler's fallthrough
+ * semantics: the first rule of a type without `fallthrough: true` finalises
+ * that type, and a file matching only a later (shadowed) rule of that type
+ * fails the build with wrangler's own actionable error.
+ */
+export declare function createModuleRulesPlugin(userRules: ModuleRule[]): EsbuildPlugin;

package/dist/moduleRules.js

@@ -0,0 +1,130 @@
+/**
+ * Translates wrangler module `rules` into an esbuild plugin so the build-mode
+ * bundle honors the same contract wrangler's own bundler honors in dev.
+ *
+ * Wrangler config rules look like
+ * `{ "type": "Text", "globs": ["**\/*.sql"], "fallthrough": true }` and make
+ * matching imports resolve to the file contents (as a string for `Text`, an
+ * `ArrayBuffer` for `Data`). Wrangler applies them — plus a set of default
+ * rules — whenever it bundles a worker (`wrangler dev`, `wrangler deploy`,
+ * and this plugin's dev sidecar). The build-mode `esbuild.build()` call in
+ * `patchWorker` runs outside wrangler, so without this plugin a `.sql` import
+ * that works in dev fails the production build with "No loader is configured".
+ * See https://github.com/oselvar/sveltekit-add-worker-exports/issues/8
+ *
+ * Wrangler exports none of its rules machinery, but miniflare (already a peer
+ * dependency) exports `compileModuleRules`/`testRegExps` with the same
+ * fallthrough semantics, so only wrangler's default rule list is replicated
+ * here. One divergence: miniflare compiles globs with `globstar: true` and
+ * matches resolved file paths, while wrangler's bundler compiles with
+ * `globstar: false` and matches import specifiers. The canonical shapes
+ * (`**\/*.sql`, `**\/*.txt`) behave identically under both.
+ */
+import { readFile } from 'node:fs/promises';
+import { compileModuleRules, globsToRegExps, testRegExps } from 'miniflare';
+export function toModuleRule(rule) {
+    return { type: rule.type, include: rule.globs, fallthrough: rule.fallthrough };
+}
+/**
+ * Wrangler's `DEFAULT_MODULE_RULES` (src/deployment-bundle/rules.ts), in
+ * miniflare's shape. Wrangler appends these after user rules everywhere it
+ * bundles, so the plugin does the same — `.sql`, `.txt`, and `.html` imports
+ * work with no `rules` config at all, matching `wrangler dev`.
+ */
+export const WRANGLER_DEFAULT_MODULE_RULES = [
+    { type: 'Text', include: ['**/*.txt', '**/*.html', '**/*.sql'] },
+    { type: 'Data', include: ['**/*.bin'] },
+    { type: 'CompiledWasm', include: ['**/*.wasm', '**/*.wasm?module'] }
+];
+/** Rules esbuild already handles natively; wrangler skips these too. */
+function isJavaScriptRuleType(type) {
+    return type === 'ESModule' || type === 'CommonJS';
+}
+/**
+ * Builds an esbuild plugin that applies `userRules` followed by wrangler's
+ * default rules, first match wins. Matching honors wrangler's fallthrough
+ * semantics: the first rule of a type without `fallthrough: true` finalises
+ * that type, and a file matching only a later (shadowed) rule of that type
+ * fails the build with wrangler's own actionable error.
+ */
+export function createModuleRulesPlugin(userRules) {
+    const allRules = [...userRules, ...WRANGLER_DEFAULT_MODULE_RULES];
+    // `compileModuleRules` keeps the same rules wrangler's `parseRules` keeps.
+    // 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.
+    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
+    // "No loader is configured".
+    const finalisedTypes = new Set();
+    const removed = [];
+    for (const rule of allRules) {
+        if (finalisedTypes.has(rule.type)) {
+            removed.push({ rule, include: globsToRegExps(rule.include, { endAnchor: true }) });
+        }
+        else if (!rule.fallthrough) {
+            finalisedTypes.add(rule.type);
+        }
+    }
+    return {
+        name: 'wrangler-module-rules',
+        setup(build) {
+            build.onLoad({ filter: /.*/ }, async (args) => {
+                // Match with `/` separators so globs behave the same on Windows.
+                const path = args.path.replaceAll('\\', '/');
+                for (const rule of kept) {
+                    if (testRegExps(rule.include, path)) {
+                        return loadModule(rule.type, args.path);
+                    }
+                }
+                for (const { rule, include } of removed) {
+                    if (testRegExps(include, path)) {
+                        return {
+                            errors: [
+                                {
+                                    text: `The file ${args.path} matched a module rule in your configuration ` +
+                                        `(${JSON.stringify({ type: rule.type, globs: rule.include })}), but was ignored because a ` +
+                                        'previous rule with the same type was not marked as `fallthrough = true`.'
+                                }
+                            ]
+                        };
+                    }
+                }
+                return undefined;
+            });
+        }
+    };
+}
+async function loadModule(type, path) {
+    switch (type) {
+        case 'Text':
+            // esbuild's text loader default-exports the contents as a string,
+            // exactly like a workerd Text module.
+            return { contents: await readFile(path, 'utf-8'), loader: 'text' };
+        case 'Data': {
+            // workerd Data modules import as an ArrayBuffer, but esbuild's
+            // `binary` loader yields a Uint8Array — so inline a stub that
+            // decodes to the exact runtime type.
+            const base64 = (await readFile(path)).toString('base64');
+            return {
+                contents: `const bytes = Uint8Array.from(atob(${JSON.stringify(base64)}), (c) => c.charCodeAt(0));\n` +
+                    'export default bytes.buffer;\n',
+                loader: 'js'
+            };
+        }
+        default:
+            // CompiledWasm / PythonModule / PythonRequirement: workerd loads
+            // these as separate deploy-time modules, which can't be inlined
+            // into the single-file _extra_exports.js bundle. (Workers forbids
+            // compiling WebAssembly from bytes at runtime.)
+            return {
+                errors: [
+                    {
+                        text: `"${type}" module rules are not supported by @oselvar/sveltekit-add-worker-exports: ` +
+                            `${path} cannot be inlined into the single-file worker bundle.`
+                    }
+                ]
+            };
+    }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@oselvar/sveltekit-add-worker-exports",
-	"version": "2.1.0",
+	"version": "2.1.2",
 	"description": "Vite plugin that adds Durable Object and Workflow exports to SvelteKit Cloudflare workers",
 	"type": "module",
 	"publishConfig": {
@@ -37,24 +37,33 @@
 	},
 	"devDependencies": {
 		"@release-it/conventional-changelog": "^11.0.1",
-		"@sveltejs/kit": "^2.64.0",
-		"@types/node": "^25.9.2",
-		"esbuild": "^0.28.0",
-		"miniflare": "^4.20260609.0",
-		"release-it": "^20.2.0",
-		"typescript": "^6.0.3",
-		"vite": "^8.0.16",
-		"vitest": "^4.1.8",
-		"wrangler": "^4.99.0"
+		"@sveltejs/kit": "^2.69.3",
+		"@types/node": "^26.1.1",
+		"esbuild": "^0.28.1",
+		"miniflare": "^4.20260710.0",
+		"release-it": "^20.2.1",
+		"typescript": "^7.0.2",
+		"vite": "^8.1.4",
+		"vitest": "^4.1.10",
+		"wrangler": "^4.111.0"
 	},
 	"scripts": {
 		"build": "tsc",
 		"test": "vitest run && tsc --noEmit",
+		"test:acceptance": "pnpm build && vitest run --config vitest.acceptance.config.ts",
 		"prepublishOnly": "tsc",
 		"release": "release-it"
 	},
+	"packageManager": "pnpm@11.9.0",
+	"devEngines": {
+		"runtime": {
+			"name": "node",
+			"version": ">=26",
+			"onFail": "warn"
+		}
+	},
 	"dependencies": {
 		"jsonc-parser": "^3.3.1",
-		"smol-toml": "^1.6.1"
+		"smol-toml": "^1.7.0"
 	}
 }