devflare 1.0.0-next.6 → 1.0.0-next.8

package/LLM.md

@@ -349,8 +349,8 @@ This table shows what each top-level config key means, which layer uses it, and
 | `limits` | worker runtime limits | compile/runtime | Yes | current native shape only models `cpu_ms` |
 | `observability` | worker logs / sampling | compile/runtime | Yes | passes through directly |
 | `migrations` | Durable Object migrations | compile/runtime | Yes | used for DO class evolution |
-| `build` | build metadata/options | schema/dev/build tooling | No direct compiler output | see caveats below |
-| `plugins` | Vite plugin list / build-time extension point | schema/build tooling | No direct compiler output | see caveats below |
+| `rolldown` | Rolldown-related config for Devflare's DO bundler | schema/dev/build tooling | No direct compiler output | `rolldown.options` is currently forwarded to DO bundling in dev; see caveats below |
+| `vite` | Vite-related config namespace and extension point | schema/build tooling | No direct compiler output | current modeled field is `vite.plugins`; raw Vite config still belongs in `vite.config.*`; see caveats below |
 | `env` | environment-specific overrides | Devflare pre-compilation merge layer | Not as nested env blocks | only a subset of top-level keys is supported inside each env block; see the dedicated section |
 | `wrangler.passthrough` | raw Wrangler fields not modeled natively | compiler/deploy | Yes | merged at top level into compiled config |
 
@@ -990,14 +990,16 @@ The current `env` schema supports overrides for these keys:
 - `limits`
 - `observability`
 - `migrations`
-- `build`
+- `rolldown`
+- `vite`
 - `wrangler`
 
 Not currently supported inside `config.env.<name>`:
 
 - `accountId`
 - `wsRoutes`
-- `plugins`
+
+Legacy aliases `build` and `plugins` are still accepted for compatibility and normalized to `rolldown` and `vite` during validation.
 
 So if you need environment-specific values for one of those unsupported keys, compute them in the outer `defineConfig()` function yourself instead of assuming `config.env` can hold them.
 
@@ -1203,28 +1205,213 @@ This is the correct escape hatch when native Devflare config is intentionally na
 
 ---
 
-## `build` and `plugins`
+## Vite and Rolldown
 
-Devflare’s schema includes:
+Vite and Rolldown both matter in Devflare, but they do **different jobs**.
+
+If users blur them together, the resulting mental model gets messy fast.
+
+### Short mental model
+
+- **Vite** is the main **application-facing** dev/build pipeline in Devflare
+- **Rolldown** is the current **Durable Object bundler** Devflare uses in local dev
+- if you are working on `vite.config.*`, the `devflare/vite` plugin, frontend HMR, or the default `devflare build` / `devflare deploy` path, you are in **Vite land**
+- if you are customizing how Durable Object source files are resolved, transformed, or bundled during local dev, you are in **Rolldown land**
+
+They are related, but they are not interchangeable.
+
+### What Vite does in Devflare
+
+Vite is Devflare’s main integration point for:
+
+- app-facing development with a local `vite.config.*`
+- frontend HMR when the package actually has a local Vite config
+- the `devflare/vite` integration surface
+- the default `devflare build` and `devflare deploy` build subprocesses, which currently run `bunx vite build`
+- SvelteKit and other framework workflows that already speak Vite natively
+
+Put differently: if you are building the main worker application experience, Devflare still primarily leans on **Vite**.
+
+### What `config.vite` is and is not
+
+The top-level `vite` field is Devflare’s **Vite-related config namespace**.
+
+Right now, its most concrete public field is:
+
+- `vite.plugins`
+
+That field exists to keep Vite-related extension points grouped under a clearly named namespace instead of using a vague top-level `plugins` field.
+
+However, it is important to be precise about what this does **not** mean:
+
+- `config.vite` is **not** a full mirror of raw Vite configuration
+- Devflare does **not** currently forward arbitrary `config.vite` keys straight into the `vite build` CLI invocation
+- raw Vite configuration still belongs in your real `vite.config.ts`, `vite.config.js`, `vite.config.mts`, or `vite.config.mjs`
+
+So the correct user-facing rule is:
+
+> Use `config.vite` for Devflare-level Vite-related metadata and extension points, but use `vite.config.*` for actual Vite build/server configuration.
+
+### What Rolldown does in Devflare
+
+Rolldown is currently used most concretely in Devflare for:
+
+- bundling Durable Object source files in local dev
+- rebuilding Durable Object bundles when watched DO files change
+- handling non-JS imports or custom transform/resolve needs inside the DO bundler path
+
+That means `rolldown` is the right top-level namespace for settings that conceptually belong to Devflare’s DO bundler.
+
+### What `config.rolldown` is and is not
+
+The top-level `rolldown` field is the public home for Devflare’s Rolldown-related config.
+
+The current shape is:
+
+- `rolldown.minify`
+- `rolldown.sourcemap`
+- `rolldown.target`
+- `rolldown.options`
+
+Where:
+
+- `rolldown.minify` and `rolldown.sourcemap` are Devflare-level default output toggles for DO bundles
+- `rolldown.options` is the raw Rolldown options bag forwarded into the DO bundler
+- `rolldown.target` is currently a lighter modeled field and should not be assumed to be fully wired through every path yet
+
+In other words, the raw Rolldown plugin and resolver surface lives under:
+
+- `rolldown.options`
+
+not under a generic `build` object.
+
+### Canonical config shape
+
+Prefer this structure in new configs:
+
+```ts
+import { defineConfig } from 'devflare'
+
+export default defineConfig({
+	name: 'my-worker',
+	vite: {
+		plugins: []
+	},
+	rolldown: {
+		minify: false,
+		sourcemap: true,
+		options: {}
+	}
+})
+```
+
+### Legacy aliases
+
+For backward compatibility, Devflare still accepts these legacy top-level aliases:
+
+- `plugins` → normalized to `vite.plugins`
+- `build` → normalized to `rolldown`
+
+That means older configs keep loading, but the preferred documented surface is now:
+
+- `vite`
+- `rolldown`
+
+### Current Rolldown support surface
+
+The current Rolldown support story is:
+
+- validated against `rolldown@1.0.0-rc.12`
+- applies most concretely to **Durable Object bundling in dev mode**
+- especially useful when DO source files import non-JS assets or need custom resolve/transform behavior
+
+The DO bundler forwards your `rolldown.options` into Rolldown while still reserving a few settings for Devflare itself:
+
+- Devflare owns the entry input path
+- Devflare keeps the platform worker-friendly (`neutral`)
+- Devflare keeps Cloudflare and Node built-ins externalized as needed for local runtime compatibility
+- Devflare injects the internal `debug` shim alias used by browser-rendering-related dependencies
+- Devflare writes single-file ESM DO bundles with `output.codeSplitting = false`
+
+That means the following kinds of settings are good candidates for `rolldown.options`:
 
-- `build`
 - `plugins`
+- `resolve`
+- `external`
+- `moduleTypes`
+- `tsconfig`
+- `transform`
+- `onLog`
+- `output.sourcemap`
+- `output.minify`
+
+One subtle but important detail:
+
+- `rolldown.minify` and `rolldown.sourcemap` act as Devflare defaults
+- `rolldown.options.output.minify` and `rolldown.options.output.sourcemap` can still override them more specifically
+
+### Svelte example for Durable Object rendering
+
+Rolldown’s plugin API is broadly Rollup-compatible, so existing Rollup plugins are often the right starting point.
+
+If a Durable Object imports `.svelte` files and renders them server-side, a practical pattern is:
+
+```ts
+import { defineConfig } from 'devflare'
+import svelte from 'rollup-plugin-svelte'
 
-Current `build` shape includes:
+export default defineConfig({
+	name: 'chat-worker',
+	files: {
+		durableObjects: 'src/do.*.ts'
+	},
+	rolldown: {
+		options: {
+			plugins: [
+				svelte({
+					compilerOptions: {
+						generate: 'ssr'
+					}
+				})
+			],
+			output: {
+				sourcemap: true
+			}
+		}
+	}
+})
+```
 
-- `target`
-- `minify`
-- `sourcemap`
-- `rolldownOptions`
+Example DO module:
 
-However, it is important to understand the current maturity of these fields:
+```ts
+import { DurableObject } from 'cloudflare:workers'
+import App from './App.svelte'
 
-- they exist in the config schema
-- they are meaningful as project-level Devflare metadata and extension points
-- but the default CLI build/deploy path still primarily runs `bunx vite build`
-- they are **not** emitted directly by `compileConfig()` into `wrangler.jsonc`
+export class ChatRenderer extends DurableObject {
+	async fetch(): Promise<Response> {
+		const { html } = App.render({ name: 'Devflare' })
 
-So do not assume that every field in `build` or every item in `plugins` is already consumed by every CLI/build path.
+		return new Response(html, {
+			headers: {
+				'content-type': 'text/html; charset=utf-8'
+			}
+		})
+	}
+}
+```
+
+### Limitation to keep in mind
+
+Rolldown is **not yet Devflare’s universal main-worker build hook**.
+
+Today, the clearest supported Rolldown-plugin path is DO bundling in dev.
+For the main fetch worker build path, Devflare still centers on Vite, so if you want full Svelte/Vite-style app compilation for the main worker, prefer the Vite or SvelteKit integration surfaces.
+
+So the practical rule is:
+
+- use **Vite** for the main app/build/framework path
+- use **Rolldown** when you need to customize Devflare’s DO bundler path
 
 When these fields matter, validate the actual Vite/build behavior in your project.
 
@@ -1529,7 +1716,7 @@ It is a combined local development system that includes:
 - Vite dev server behavior
 - Miniflare-backed Cloudflare bindings
 - bridge-backed communication between Bun/Node-side tooling and the worker runtime
-- DO-oriented local orchestration and bundling behavior
+- DO-oriented local orchestration and Rolldown-based bundling/watch behavior
 - websocket-aware proxying for local DO workflows
 - browser-shim behavior for browser rendering
 - local migration handling when relevant resources are configured
@@ -1779,6 +1966,11 @@ Use it when you need Devflare-aware Vite integration, worker-aware transforms, o
 
 The Vite plugin does more than inject one helper.
 
+If you are deciding between `vite` and `rolldown`, this is the headline distinction:
+
+- `devflare/vite` is the **main application-facing integration**
+- `rolldown` config is the **DO bundler customization surface**
+
 It currently:
 
 - loads and compiles `devflare.config.ts`
@@ -1954,7 +2146,8 @@ These are core Devflare strengths today:
 	- do not assume arbitrary JSON-valued vars are a native Devflare feature
 
 3. **`config.env` only supports a subset of top-level config keys**
-	- it does not currently support environment-local `accountId`, `wsRoutes`, or `plugins`
+	- it does not currently support environment-local `accountId` or `wsRoutes`
+	- legacy `build` and `plugins` are accepted as aliases, but the canonical env-facing keys are `rolldown` and `vite`
 
 4. **`config.env` uses `defu` merge semantics**
 	- nested objects inherit from the base config
@@ -1992,9 +2185,11 @@ These are core Devflare strengths today:
 	 - workflow discovery naming is modeled
 	 - but the broader runtime/compiler/test story is less mature than the most central surfaces
 
-13. **`build` and `plugins` are schema-level extension points, not guaranteed end-to-end behavior in every path**
+13. **`vite` and `rolldown` are not equally wired in every path**
+	 - `rolldown.options` is currently wired into DO bundling in dev and validated against `rolldown@1.0.0-rc.12`
+	 - `vite` is the clearer Vite-side namespace, but it is still not a full mirror of raw `vite.config.*`
 	 - the default build/deploy commands still center on Vite output
-	 - verify actual project behavior when relying on these fields
+	 - verify actual project behavior when relying on these fields outside the DO bundler path
 
 14. **there is no stable public local-R2 browser URL contract today**
 	 - Devflare uses internal `/_devflare/*` routes for dev-server behavior
@@ -2141,4 +2336,5 @@ If you only remember a few things, remember these:
 12. use `ref()` for multi-worker composition instead of magic strings
 13. store R2 object keys as the durable identifier instead of storing full delivery URLs
 14. treat local preview or inspector URLs as dev conveniences, not as the production file-delivery contract
-15. when native config does not cover a Wrangler feature, use `wrangler.passthrough`
+15. Vite is the main application-facing build path, while Rolldown is currently the DO bundler path
+16. when native config does not cover a Wrangler feature, use `wrangler.passthrough`

package/README.md

@@ -178,13 +178,42 @@ These are the main config keys Devflare understands today.
 | `limits` | worker resource limits |
 | `observability` | worker logs / sampling |
 | `migrations` | Durable Object migrations |
-| `build` | build-related metadata/options |
-| `plugins` | plugin extension point |
+| `rolldown` | Rolldown-related config for Devflare’s DO bundler |
+| `vite` | Vite-related config namespace and extension point |
 | `env` | environment-specific overrides |
 | `wrangler.passthrough` | escape hatch for Wrangler fields not modeled natively |
 
 ---
 
+## Vite and Rolldown
+
+Devflare uses both tools, but for different layers of the workflow.
+
+- **Vite** is the main application-facing dev/build pipeline
+- **Rolldown** is the current Durable Object bundler path in local dev
+
+Use the top-level config namespaces like this:
+
+- `vite` for Devflare-level Vite-related config such as `vite.plugins`
+- `rolldown` for Devflare’s DO bundler settings, especially `rolldown.options`
+
+Important distinction:
+
+- raw Vite configuration still belongs in `vite.config.*`
+- raw Rolldown plugin/options for the DO bundler belong in `rolldown.options`
+
+Legacy aliases are still accepted for compatibility:
+
+- `plugins` → `vite.plugins`
+- `build` → `rolldown`
+
+If you are deciding which one matters for your task, the simple rule is:
+
+- main app/frontend/framework build path → **Vite**
+- Durable Object bundler customization path → **Rolldown**
+
+---
+
 ## Env files, `vars`, and `secrets`
 
 This is the most important config nuance to understand.
@@ -542,9 +571,11 @@ Devflare has a broad surface area, but not every feature is equally mature.
    - `ref().worker('Entrypoint')` is modeled at the Devflare layer
    - validate deployment output if named entrypoint wiring is critical to your app
 
-5. **workflows, `build`, and `plugins` are lighter than the most central surfaces**
-   - they exist and matter
-   - but they are not as battle-hardened as the fetch/queue/DO/test path
+5. **workflows, `vite`, and `rolldown` are lighter than the most central surfaces**
+	 - they exist and matter
+	 - `rolldown.options` is now wired into DO bundling in dev
+	 - `vite` is the clearer Vite-side namespace, but raw Vite config still lives in `vite.config.*`
+	 - they are not as battle-hardened as the fetch/queue/DO/test path
 
 6. **use `wrangler.passthrough` for unsupported native fields**
    - if Wrangler supports something Devflare does not model yet, passthrough is the supported escape hatch

package/dist/{build-nz5yrj7f.js → build-9myaxf07.js}

@@ -1,6 +1,12 @@
+import {
+  detectViteProject
+} from "./index-18hvb6gb.js";
 import {
   getDependencies
 } from "./index-1xpj0m4r.js";
+import {
+  prepareComposedWorkerEntrypoint
+} from "./index-a0fjkq68.js";
 import {
   compileConfig,
   writeWranglerConfig
@@ -19,12 +25,23 @@ async function runBuildCommand(parsed, logger, options) {
   try {
     const config = await loadConfig({ cwd, configFile: configPath });
     logger.info(`Building: ${config.name}`);
+    const composedMainEntry = await prepareComposedWorkerEntrypoint(cwd, config, environment);
     const wranglerConfig = compileConfig(config, environment);
+    if (composedMainEntry) {
+      wranglerConfig.main = composedMainEntry;
+      logger.info(`Generated composed worker entry: ${composedMainEntry}`);
+    }
     await writeWranglerConfig(cwd, wranglerConfig);
     logger.success("Generated wrangler.jsonc");
-    const { exec } = await getDependencies();
+    const deps = await getDependencies();
+    const viteProject = await detectViteProject(cwd, deps.fs);
+    if (!viteProject.shouldStartVite) {
+      logger.info("Skipping Vite build (no local vite.config.* found for this package)");
+      logger.success("Build complete!");
+      return { exitCode: 0 };
+    }
     logger.info("Running vite build...");
-    const proc = await exec.exec("bunx", ["vite", "build"], {
+    const proc = await deps.exec.exec("bunx", ["vite", "build"], {
       cwd,
       stdio: "inherit",
       env: {

package/dist/cli/commands/build.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"build.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/build.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAC9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AAKjE,wBAAsB,eAAe,CACpC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CA+CpB"}
+{"version":3,"file":"build.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/build.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAC9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AAOjE,wBAAsB,eAAe,CACpC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CA2DpB"}

package/dist/cli/commands/deploy.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"deploy.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/deploy.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAC9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AAKjE,wBAAsB,gBAAgB,CACrC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CAsEpB"}
+{"version":3,"file":"deploy.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/deploy.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAC9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AAOjE,wBAAsB,gBAAgB,CACrC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CAgFpB"}

package/dist/cli/commands/types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/types.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAE9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AA0oBjE,wBAAsB,eAAe,CACpC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CAwHpB"}
+{"version":3,"file":"types.d.ts","sourceRoot":"","sources":["../../../src/cli/commands/types.ts"],"names":[],"mappings":"AAIA,OAAO,EAAE,KAAK,eAAe,EAAE,MAAM,SAAS,CAAA;AAE9C,OAAO,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,SAAS,EAAE,MAAM,UAAU,CAAA;AA0qBjE,wBAAsB,eAAe,CACpC,MAAM,EAAE,UAAU,EAClB,MAAM,EAAE,eAAe,EACvB,OAAO,EAAE,UAAU,GACjB,OAAO,CAAC,SAAS,CAAC,CA2HpB"}

package/dist/{deploy-a5pcxd5w.js → deploy-h1wz5p7m.js}

@@ -1,6 +1,12 @@
+import {
+  detectViteProject
+} from "./index-18hvb6gb.js";
 import {
   getDependencies
 } from "./index-1xpj0m4r.js";
+import {
+  prepareComposedWorkerEntrypoint
+} from "./index-a0fjkq68.js";
 import {
   compileConfig,
   stringifyConfig,
@@ -21,7 +27,12 @@ async function runDeployCommand(parsed, logger, options) {
   try {
     const config = await loadConfig({ cwd, configFile: configPath });
     logger.info(`Deploying: ${config.name}`);
+    const composedMainEntry = await prepareComposedWorkerEntrypoint(cwd, config, environment);
     const wranglerConfig = compileConfig(config, environment);
+    if (composedMainEntry) {
+      wranglerConfig.main = composedMainEntry;
+      logger.info(`Generated composed worker entry: ${composedMainEntry}`);
+    }
     if (dryRun) {
       logger.info("Dry run - skipping actual deployment");
       logger.info("Would deploy with wrangler config:");
@@ -30,22 +41,27 @@ async function runDeployCommand(parsed, logger, options) {
     }
     await writeWranglerConfig(cwd, wranglerConfig);
     logger.debug("Generated wrangler.jsonc");
-    const { exec } = await getDependencies();
-    logger.info("Building...");
-    const buildProc = await exec.exec("bunx", ["vite", "build"], {
-      cwd,
-      stdio: "inherit"
-    });
-    if (buildProc.exitCode !== 0) {
-      logger.error("Build failed");
-      return { exitCode: 1 };
+    const deps = await getDependencies();
+    const viteProject = await detectViteProject(cwd, deps.fs);
+    if (viteProject.shouldStartVite) {
+      logger.info("Building...");
+      const buildProc = await deps.exec.exec("bunx", ["vite", "build"], {
+        cwd,
+        stdio: "inherit"
+      });
+      if (buildProc.exitCode !== 0) {
+        logger.error("Build failed");
+        return { exitCode: 1 };
+      }
+    } else {
+      logger.info("Skipping Vite build (no local vite.config.* found for this package)");
     }
     logger.info("Deploying with wrangler...");
     const wranglerArgs = ["wrangler", "deploy"];
     if (environment) {
       wranglerArgs.push("--env", environment);
     }
-    const deployProc = await exec.exec("bunx", wranglerArgs, {
+    const deployProc = await deps.exec.exec("bunx", wranglerArgs, {
       cwd,
       stdio: "inherit"
     });