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

package/README.md

@@ -217,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 |
@@ -232,7 +275,7 @@ declare global {
 
 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:
 

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
@@ -82,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
@@ -117,6 +119,27 @@ export function addWorkerExports(options) {
  * 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');
@@ -143,6 +166,10 @@ async function patchWorker(options) {
     // `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,
@@ -151,6 +178,7 @@ async function patchWorker(options) {
         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.
@@ -210,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;
@@ -227,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.1",
+	"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.66.0",
-		"@types/node": "^26.0.0",
+		"@sveltejs/kit": "^2.69.3",
+		"@types/node": "^26.1.1",
 		"esbuild": "^0.28.1",
-		"miniflare": "^4.20260617.1",
-		"release-it": "^20.2.0",
-		"typescript": "^6.0.3",
-		"vite": "^8.0.16",
-		"vitest": "^4.1.9",
-		"wrangler": "^4.103.0"
+		"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"
 	}
 }