void 0.24.0 → 0.26.0

package/skills/void/docs/reference/cli/platform-config.md

@@ -20,7 +20,7 @@ void platform config plans default <plan-id>
 void platform config plans sync
 ```
 
-Use `--plan` to preview changes and affected accounts; scripted mutations require `--yes`. Every command supports `--connection <registered-id-or-url>` and `--json`. `show` reports the effective limits, default, assignments, and pending account updates. `reset` restores a built-in plan's original limits and build instance size. Archived plans keep their existing accounts but cannot receive new assignments; change the default before archiving it. `remove` requires a replacement for a plan that has accounts or is the default. Changing the default affects only new accounts.
+Use `--plan` to preview changes and affected accounts; scripted mutations require `--yes`. Every command supports `--connection <slug-or-url>` and `--json`. `show` reports the effective limits, default, assignments, and pending account updates. `reset` restores a built-in plan's original limits and build instance size. Archived plans keep their existing accounts but cannot receive new assignments; change the default before archiving it. `remove` requires a replacement for a plan that has accounts or is the default. Changing the default affects only new accounts.
 
 For `add` and `set`, `--file` reads a JSON object with optional `name`, `limits`, `buildInstanceType`, and boolean `allowShortSlugs`. `limits` is a partial object of nonnegative whole numbers; `0` means unlimited by the plan. Build timeouts remain capped at the platform maximum of 60 minutes; `0` uses that maximum. Omitted settings keep their current values or the copied plan's values. `buildInstanceType` is `standard-3` or `standard-4`. `allowShortSlugs` permits future assignments of project slugs of five characters or fewer; existing URLs remain available. Storage quotas are not editable. See [Plans and Limits](../../guide/platform/administration/plans.md) for supported limits and examples.
 
@@ -60,7 +60,7 @@ alternative; the last method cannot be disabled. Disabling revokes human session
 created through that method, including operator sessions. Scoped deployment tokens
 remain valid; a human login token used as `VOID_TOKEN` is still revoked.
 
-Commands accept `--connection <registered-id-or-url>` and `--json`. Changes accept
+Commands accept `--connection <slug-or-url>` and `--json`. Changes accept
 `--plan` or `--yes`. For scripted configuration, use `--file <path>` for the
 nonsecret fields and `--client-secret-env <name>` for the environment variable
 containing the secret. Omit the secret when editing to retain its saved value.

package/skills/void/docs/reference/cli/platform-installation.md

@@ -101,12 +101,12 @@ void platform rollback [id] --runtime <earlier-path> [--from-runtime <current-pa
 void platform repair [id] [--runtime <path>] [--dashboard-url <origin>] [--plan] [--yes]
 void platform disable [id] [--plan] [--yes]
 void platform enable [id] [--runtime <path>] [--plan] [--yes]
-void platform uninstall [id] [--plan] [--purge-data] [--keep-zone] [--yes]
+void platform uninstall [id] [--plan] [--purge-data | --purge-resources] [--keep-zone] [--yes]
 ```
 
 `discover --installation` limits recovery and endpoint verification to one installation in a shared Cloudflare account.
 
-Omit `id` when only one installation is configured, or choose from the interactive picker. Non-interactive commands need an ID when several installations exist. Commands that make changes also require `--yes`; `--plan` only previews changes.
+Use the installation slug shown beside its name in `void platform list`. Installation IDs and saved connection IDs also work. Lifecycle commands require local installation records; use `discover` to restore them on another machine. Omit `id` when only one installation is configured, or choose from the interactive picker. Non-interactive commands need a slug or ID when several installations exist. Commands that make changes also require `--yes`; `--plan` only previews changes.
 
 To add or explicitly change a separately deployed dashboard after installation,
 use `repair --dashboard-url <origin>` or `upgrade --dashboard-url <origin>`.
@@ -115,15 +115,15 @@ dashboard origin before maintenance can proceed. See [Optional Dashboard](../../
 
 After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. An upgrade that preserves every deployed Worker also preserves its secrets. For an email-enabled installation without its encrypted recovery file, restore `VOID_PLATFORM_EMAIL_SIGNING_SECRET`; recreating only the email gateway needs that key and does not need the Cloudflare runtime token or JWT signing key. Recreating the API or proxy also requires the email key when email is enabled, in addition to their normal secrets. Recreating the API requires its original runtime-token, GitHub, R2, JWT, and project-encryption values; recreating the proxy requires the runtime token and JWT signing key.
 
-| Command     | Behavior                                                                                      |
-| ----------- | --------------------------------------------------------------------------------------------- |
-| `discover`  | Verifies remote ownership and restores local installation records without downloading secrets |
-| `repair`    | Recreates missing resources owned by the installer                                            |
-| `upgrade`   | Deploys the selected runtime and supported pending migrations                                 |
-| `rollback`  | Restores a declared-compatible earlier runtime without reversing PostgreSQL migrations        |
-| `disable`   | Blocks platform traffic through routing storage without removing data                         |
-| `enable`    | Restores traffic after checking the platform                                                  |
-| `uninstall` | Blocks traffic and removes eligible resources, retaining data by default                      |
+| Command     | Behavior                                                                                                    |
+| ----------- | ----------------------------------------------------------------------------------------------------------- |
+| `discover`  | Verifies remote ownership and restores local installation records without downloading secrets               |
+| `repair`    | Recreates missing resources owned by the installer                                                          |
+| `upgrade`   | Deploys the selected runtime and supported pending migrations                                               |
+| `rollback`  | Restores a declared-compatible earlier runtime without reversing PostgreSQL migrations                      |
+| `disable`   | Blocks app traffic and the platform API without removing data; only admin status and sign-in stay available |
+| `enable`    | Redeploys and verifies the platform Workers, then restores traffic                                          |
+| `uninstall` | Blocks traffic and removes eligible resources, retaining data by default                                    |
 
 Repair and upgrade preserve disabled state. New, resumed, and previously disabled installations block user traffic until all target Workers pass verification; the installer's health probes can still run. Routes and custom domains remain attached.
 
@@ -137,6 +137,8 @@ An upgrade completes after the new Workers pass health checks. If rollout fails,
 
 `platform rollback` restores a compatible earlier runtime without reversing database migrations. Pass its files with `--runtime`; if the installed version is custom, also supply that version with `--from-runtime`. Void refuses incompatible targets.
 
-Uninstall verifies remote ownership before removing anything. Data resources are retained unless you pass `--purge-data`. Workers, the Queues they use, R2, AI Gateway, DNS records, routes, custom domains, adopted resources, external PostgreSQL, and zones are always retained for manual review.
+Uninstall verifies remote ownership before removing anything. Data resources are retained unless you pass `--purge-data`. Workers, the Queues they use, R2, AI Gateway, DNS records, routes, custom domains, adopted resources, external PostgreSQL, and zones are retained for manual review.
+
+`--purge-resources` includes `--purge-data` and also deletes every other resource the installation created, including Workers, Queues, R2, AI Gateway, the platform DNS record, routes, custom domains, and installer-created Access resources. It removes only the Email Routing rules that send mail to the platform email gateway, and keeps zones, adopted resources, external PostgreSQL, other Email Routing settings, and API tokens. A route, custom domain, DNS record, or Access resource that no longer matches the installation's record is kept and listed. It refuses before any change while projects remain or resource reads are denied. Use the Edit permissions listed by `--plan`; read checks cannot verify them, so a denied deletion can stop uninstall after changes have begun. Rerun the same command to continue after an interruption, or after a plain or `--purge-data` uninstall stopped.
 
 See [Disable and Uninstall](../../guide/platform/installation/uninstall.md#remove-retained-resources) for the full removal policy and the cleanup order.

package/skills/void/docs/reference/cli/platform-operations.md

@@ -17,11 +17,7 @@ void platform deployment migrate-assets <id> [--cursor <cursor>] [--plan|--yes]
 
 Cancellation applies while a deployment is pending, uploading, migrating, or prerendering, and can be requested again while it is canceling. A deployment that has begun switching traffic, is compensating for a failure, or has finished cannot be canceled through this command.
 
-`migrate-assets` copies legacy assets to scoped R2 storage, verifies their contents, and updates each batch only after all its assets are verified. Original assets remain in place, and application traffic stays on the same deployment. Upgrade the platform runtime before using this command. Migrate both active deployments and retained rollback deployments before removing support for older asset storage.
-
-Use `--plan` to preview the first batch. Applying authorizes all remaining batches for that deployment; the CLI previews each batch and prints its result, including `nextCursor`. With `--json`, results are JSON Lines. If a later batch fails or the command is interrupted, resume with the cursor from the last successful result. An ambiguous request is never retried automatically; inspect the deployment before resuming. A completed migration reports `complete: true` and `nextCursor: null`.
-
-Use [`void platform system asset-migrations`](#operator-system) to find deployments requiring migration. Inspect every inventory page, migrate each deployment with `needsMigration` greater than zero, then inspect every page again. Include retained rollback deployments and stored bundles. Investigate rows marked `invalid` before considering migration complete. Keep the older asset readers until the full inventory is valid and no protected deployment needs migration.
+`migrate-assets` copies a deployment's legacy assets to scoped R2 storage without changing application traffic. Use `--plan` to preview and `--cursor` to resume from a successful batch. Original assets remain in place.
 
 Read its runtime logs with:
 
@@ -44,7 +40,7 @@ void platform build logs <id> [--since <sequence>] [--limit <n>] [--follow]
 
 Build logs start at sequence `0` and return up to 500 lines. Use the returned `lastSeq` as `--since` to continue; `--limit` accepts 1 to 500. Container log retrieval requires managed builds to be enabled. GitHub Actions builds return an external log URL.
 
-Following waits for the final logs after the build becomes terminal. If completion cannot be confirmed within two minutes, the command exits with an error. Older builds without a completion signal may wait for 30 seconds without new lines before following stops.
+Following waits for the final logs after the build becomes terminal. If completion cannot be confirmed within two minutes, the command exits with an error.
 
 ## System {#operator-system}
 
@@ -62,11 +58,11 @@ void platform system sandbox-drain [--cursor <opaque-cursor>]
 
 `overview` shows platform totals and recent activity. `health` checks the configured services and database, and exits with a nonzero status if a check fails. `cli-versions` reports the CLI versions used by deployments.
 
-`asset-migrations` inventories active deployments, retained rollback deployments, and deployments with stored bundles. It reports their asset counts, `needsMigration`, and an `invalid` flag for unreadable metadata. Read all pages using the response's pagination fields. Migrate each deployment with `needsMigration` greater than zero through [`deployment migrate-assets`](#operator-deployments), then rerun the full inventory. Migration keeps the original assets; removing those assets or their older readers requires separate verification.
+`asset-migrations` inventories stored deployment assets and reports `needsMigration` and `invalid` counts. Use the response's pagination fields to read all entries.
 
 `events` shows the administrator, target, and outcome of changes. A pending event means the outcome has not been recorded. Previews and session login/logout do not create these events. `backfill-queue-tokens` repairs older queue entries that are missing authentication tokens and supports `--plan` before applying the repair.
 
-Use `sandbox-drain` when an upgrade from the legacy tenant-owned Sandbox runtime asks you to finish cleanup. Preview with `--plan`; pass the returned `nextCursor` as `--cursor` to inspect later pages. Apply with `--yes` and rerun until it reports `complete: true`, then rerun the interrupted upgrade. Application traffic stays paused during cleanup, while administrator login remains available. The completed upgrade enables the current managed Sandbox controller automatically.
+`sandbox-drain` removes legacy tenant-owned Sandbox resources. Use `--plan` to preview and `--yes` to apply, then pass `nextCursor` as `--cursor` to continue. Application traffic stays paused during cleanup.
 
 Use the [platform lifecycle commands](./platform-installation.md#lifecycle-commands) to maintain your installation's Workers.
 

package/skills/void/docs/reference/cli/platform.md

@@ -14,13 +14,20 @@ void platform use [id]
 void platform status [id]
 ```
 
-`use` and `status` auto-select the only configured platform; with multiple platforms they show a picker interactively and require an id or URL in non-interactive use. A project with a recorded platform URL keeps using that platform when the global default changes.
+`list` shows the currently selected platform first, followed by other saved platforms. For a platform with local installation records, its installation slug appears beside its name, such as `Cloudflare Void (cloudflare)`. Select it with `void platform use cloudflare`. For a connected platform without a local installation slug, use its printed API URL.
+
+`use` and `status` accept an installation slug, display name, saved ID, or API URL. If a slug or name matches several platforms, use the API URL to choose one. They auto-select the only configured platform; with multiple platforms they show a picker interactively and require an explicit selector in non-interactive use. A project with a recorded platform URL keeps using that platform when the global default changes.
+
+For a self-hosted installation, `status <installation-id>` prints locally saved
+lifecycle progress before checking the live API. The saved checkpoint may be out
+of date. If live discovery fails during maintenance, the command still shows that
+checkpoint and exits with an error; it does not confirm current availability.
 
 ## Operator commands {#operator-commands}
 
 Use `void platform` to administer the users and apps on your selected platform. Start with the [Platform Administration guide](../../guide/platform-administration.md) for signing in, giving people access, and investigating deployments.
 
-Every command below accepts `--connection <registered-id-or-url>` to select a platform and `--json` for structured output. Without `--connection`, Void uses `VOID_API_URL` if set, then the active platform connection. Application project files do not change this selection.
+Every command below accepts `--connection <slug-or-url>` to select a registered platform and `--json` for structured output. Display names and saved IDs also work. Without `--connection`, Void uses `VOID_API_URL` if set, then the active platform connection. Application project files do not change this selection.
 
 ### Making Changes {#making-changes}
 

package/skills/void/docs/reference/cli.md

@@ -56,7 +56,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void account login`              | Authenticate with a Void platform                                             |
 | `void cloudflare login`           | Authenticate with Cloudflare through Void                                     |
 | `void platform install`           | Install a company Void platform in Cloudflare                                 |
-| `void connect <url>`              | Connect the CLI to a Void platform                                            |
+| `void connect <url>`              | Connect the CLI to a Void platform; hostnames default to HTTPS                |
 | `void project link`               | Link directory to a project                                                   |
 | `void project logs`               | Show runtime logs from deployed project                                       |
 | `void project requests`           | Show request-level traffic (status, method, timing)                           |

package/skills/void/docs/reference/resource-inference.md

@@ -17,6 +17,7 @@ Void automatically detects which Cloudflare resources your project uses by scann
 | `SANDBOX`        | Managed Sandbox capability | `import { getSandbox } from "void/sandbox"`                                                                                                                      | `getSandbox()`; native Cloudflare also exposes `env.SANDBOX` / `c.env.SANDBOX` |
 | Auth             | none                       | `import { ... } from "void/auth"` or `import { auth } from "void/client"` / `void/client/react` / `void/client/vue` / `void/client/svelte` / `void/client/solid` | none                                                                           |
 | `QUEUE_*`        | `Queue`                    | `import { queues } from "void/queues"`                                                                                                                           | `env.QUEUE_*`                                                                  |
+| `VOID_LIVE`      | `DurableObjectNamespace`   | `import { defineLiveStream } from "void/live"`                                                                                                                   | n/a                                                                            |
 | filename-derived | `DurableObjectNamespace`   | A default-exported `defineDurableState()` module in `durable-objects/`                                                                                           | n/a                                                                            |
 
 Auth detection also triggers when importing the `auth` specifier from `void/client` or a framework-specific client subpath such as `void/client/react` (but not when importing only `fetch`).
@@ -27,7 +28,7 @@ Durable state is inferred from files in `durable-objects/`. For example, `durabl
 
 ### Standard mode
 
-When using Void's built-in routing (no meta-framework), these directories are scanned:
+Native Void apps scan these directories by default. With [`sourceDir`](./config.md#sourcedir) configured, Void scans that source tree instead:
 
 | Directory     | Contains                                    |
 | ------------- | ------------------------------------------- |
@@ -36,10 +37,12 @@ When using Void's built-in routing (no meta-framework), these directories are sc
 | `queues/`     | Queue consumers                             |
 | `pages/`      | Page components and `.server.ts` companions |
 | `crons/`      | Scheduled job handlers                      |
+| `email/`      | Inbound email handlers                      |
+| `src/`        | Application source                          |
 
 ### Framework mode
 
-When a meta-framework is detected (TanStack Start, React Router, SvelteKit, Nuxt, or Astro), a broader set of directories is scanned instead:
+For [supported meta frameworks](../integrations/frameworks/overview.md), Void scans these directories:
 
 | Directory | Contains                |
 | --------- | ----------------------- |
@@ -47,17 +50,18 @@ When a meta-framework is detected (TanStack Start, React Router, SvelteKit, Nuxt
 | `app/`    | Framework app directory |
 | `routes/` | Framework routes        |
 | `server/` | Server-side code        |
+| `pages/`  | Framework pages         |
+| `crons/`  | Scheduled job handlers  |
+| `queues/` | Queue consumers         |
 
-Framework detection checks `package.json` for `@tanstack/react-start`, `@react-router/dev`, `@sveltejs/kit`, `nuxt`, or `astro` in dependencies.
-
-For SvelteKit, Nuxt, and Astro, add `voidPlugin()` to the framework's Vite config to enable inference during dev. See [Frameworks Integration](../integrations/frameworks/overview.md) for setup details.
+Framework detection uses `package.json` dependencies and dev dependencies. Add `voidPlugin()` to your framework's Vite config to enable inference during development. The integration guides show the setup for each framework.
 
 ### Always scanned
 
 Regardless of mode, these are always checked:
 
 - **SSR entry** such as `src/main.ssr.ts`, for SSR apps that access bindings during rendering
-- **`src/`**, which is always scanned for auth imports unless it is already in the scan list for framework mode
+- **Application source** in `src/` or your configured `sourceDir`, including resource and auth imports
 - **`durable-objects/`**, which is scanned for typed Durable Object state modules in native Void apps
 
 ## Custom Scan Directories
@@ -72,7 +76,7 @@ If your project organizes code in non-standard directories, you can override whi
 }
 ```
 
-Paths are relative to the project root. When `inference.scanDirs` is set, it replaces the default directories entirely. Defaults for the current mode are not merged in. The SSR entry and `src/` auth scan still apply either way.
+Paths are relative to the project root. When `inference.scanDirs` is set, it replaces the default directories entirely. The SSR entry and application source scan still apply.
 
 ## Explicit Binding Overrides
 
@@ -95,4 +99,4 @@ Explicit values override only their named bindings. Omitted bindings continue to
 
 ## File Types
 
-Inference scans files matching `**/*.{ts,tsx,mts,js,jsx,mjs}` within each directory. Non-JS files (CSS, HTML, images) are ignored.
+Inference scans `.ts`, `.tsx`, `.mts`, `.js`, `.jsx`, `.mjs`, and Astro frontmatter. Put server resource imports in these files or a page's `.server.ts` companion; Vue and Svelte component files are not scanned directly.

package/dist/cf-build-output-_0HNWysu.mjs

@@ -1,2 +0,0 @@
-import { t as prepareCfBuildOutput } from "./cf-build-output-BPqOT964.mjs";
-export { prepareCfBuildOutput };

package/dist/client-B9UBI03V.mjs

@@ -1,2 +0,0 @@
-import { n as PlatformClient } from "./client-DKAsFA4X.mjs";
-export { PlatformClient };

package/dist/deploy-irP5q0-x.mjs

@@ -1,2 +0,0 @@
-import { A as parseRootWranglerConfig, J as runDeploy, f as checkWranglerMigrationApplySet } from "./deploy-gCVaiJbS.mjs";
-export { checkWranglerMigrationApplySet, parseRootWranglerConfig, runDeploy };

package/dist/gen-DvQTWzDU.mjs

@@ -1,2 +0,0 @@
-import { r as runGenCommand } from "./gen-CshAkukR.mjs";
-export { runGenCommand };

package/dist/help-mabuIV98.mjs

@@ -1,2 +0,0 @@
-import { r as printHelpPage } from "./help-Dotbf6iz.mjs";
-export { printHelpPage };

package/dist/login-DIy9Sb-U.mjs

@@ -1,2 +0,0 @@
-import { r as selectPlatformLoginMethod } from "./login-BuiMyUrx.mjs";
-export { selectPlatformLoginMethod };

package/dist/migrate-BCiJ8w0f.mjs

@@ -1,2 +0,0 @@
-import { n as runMigrateCommand } from "./migrate-q4_njtaW.mjs";
-export { runMigrateCommand };

package/dist/plan-D1Q5rf-r.mjs

@@ -1,2 +0,0 @@
-import { n as buildMigrationPlanBundle } from "./plan-NPpwZ_kc.mjs";
-export { buildMigrationPlanBundle };

package/dist/platform-args-DdnM6WIf.mjs

@@ -1,2 +0,0 @@
-import { t as parsePlatformArgs } from "./platform-args-3k8X9-H_.mjs";
-export { parsePlatformArgs };

package/dist/platform-management-DG47jys8.mjs

@@ -1,2 +0,0 @@
-import { c as selectAuthoritativePlatformManifest, s as runInstalledPlatformCommand, u as verifyPlatformInstallationOwnership } from "./platform-management-CWOQOWXm.mjs";
-export { runInstalledPlatformCommand, selectAuthoritativePlatformManifest, verifyPlatformInstallationOwnership };

package/dist/prepare-CnjcTV2s.mjs

@@ -1,2 +0,0 @@
-import { t as prepareProject } from "./prepare-DnaKBi--.mjs";
-export { prepareProject };

package/dist/validate-Dq_L3s0S.mjs

@@ -1,2 +0,0 @@
-import { i as validateMigrations } from "./validate-ctOrgiS3.mjs";
-export { validateMigrations };

package/skills/void/docs/guide/env-migration.md

@@ -1,109 +0,0 @@
-# Environment migration
-
-Use `.env` for local development and remote secrets for server-side production values.
-
-## 1. Back up and consolidate values
-
-Before changing any dotenv files, securely back up the production values you need to migrate outside the project directory. Keep them out of Git. Do not delete the original files until the upload and verification in step 3 succeed.
-
-Merge the values you still need locally into `.env`:
-
-```text
-.env.local
-.env.development
-.env.development.local
-→ .env
-```
-
-Keep the legacy files for now. You will remove them in step 5, after migrating their values.
-
-Ensure `.env` is ignored by Git:
-
-```text
-.env
-```
-
-## 2. Update `env.ts`
-
-Remove `.secret()` and `.public()` from `env.ts` before running secret commands.
-
-Change:
-
-```ts
-export default defineEnv({
-  STRIPE_KEY: string().secret(),
-  VITE_API_ORIGIN: url().public(),
-});
-```
-
-to:
-
-```ts
-export default defineEnv({
-  STRIPE_KEY: string(),
-  VITE_API_ORIGIN: url(),
-});
-```
-
-Server keys have no `VITE_` prefix; client keys do.
-
-## 3. Upload server secrets
-
-For managed Void projects, upload each non-client schema key:
-
-```sh
-void secret put DATABASE_URL
-void secret put STRIPE_KEY
-```
-
-To migrate a production file in one pass, prepare a copy outside the project directory containing only server keys declared in `env.ts`, then upload it:
-
-```sh
-void secret sync /secure/path/production-secrets.txt
-```
-
-The sync command validates every entry against `env.ts`. It rejects undeclared names, invalid values, and client-prefixed names. Keep client-prefixed values for step 4 instead of including them in this file.
-
-For direct Cloudflare deployments, select Cloudflare and use the same commands:
-
-```sh
-void connect --platform cloudflare
-void secret put DATABASE_URL
-void secret put STRIPE_KEY
-```
-
-After the upload succeeds, confirm that all expected server names appear in the remote store:
-
-```sh
-void secret list
-```
-
-If an upload fails or a name is missing, keep the source values and retry before continuing.
-
-For direct Cloudflare deployments, remove the migrated server keys from `cloudflare.vars` in `void.config.ts` after confirming the upload. Void now treats any schema-declared server key in Worker `vars` as an error.
-
-## 4. Set client build values
-
-Move `VITE_*` production values to CI/build-shell variables, or make the value an explicit schema default:
-
-```sh
-export VITE_API_ORIGIN=https://api.example.com
-```
-
-Keep these variables set for the remote check and deployment in step 5. Client values are compiled into browser assets and are public.
-
-These values are also available during server rendering. Do not upload them as remote secrets.
-
-## 5. Remove old files and verify
-
-Once the local values are in `.env`, the server values are uploaded and listed remotely, and the client values are available to the build, delete every `.env.*` file, `.env.example`, and `.dev.vars*` file from the project. Keep the secure backup until verification succeeds. Environment checks and deployment reject these old files.
-
-Use `env.ts` as the checked-in list of names, types, defaults, and requiredness. `void env example` is no longer supported.
-
-Then verify:
-
-```sh
-void env check
-void env check --remote
-void deploy
-```

package/dist/{cf-build-output-BPqOT964.mjs → cf-build-output-U8o1Gl6X.mjs}

@@ -3,8 +3,8 @@ import { copyFileSync, cpSync, existsSync, mkdirSync, mkdtempSync, readFileSync,
 import { fileURLToPath } from "node:url";
 import { randomUUID } from "node:crypto";
 import { tmpdir } from "node:os";
-import { spawn, spawnSync } from "node:child_process";
 import { isDeepStrictEqual } from "node:util";
+import { spawn, spawnSync } from "node:child_process";
 import { getWorkerBundleDir, normalizeDirectoryName, readBuildOutput, writeAssets, writeContainerConfig, writeRootConfig, writeWorkerConfig } from "@cloudflare/build-output-utils";
 import { InputConfigSchema, OutputContainerSchema } from "@cloudflare/config";
 import ignore from "ignore";

package/dist/{env-validation-C_8tPdhs.mjs → env-validation-vBSQ8gw5.mjs}

@@ -5,8 +5,8 @@ import { a as loadLocalEnv, i as isClientEnvKey, r as findLegacyEnvFiles } from
 import { c as resolveCloudflareOperationArgv, n as decodeCloudflareOperationResult, r as encodeCloudflareOperation } from "./cloudflare-process-B-wekeR6.mjs";
 import { existsSync, readFileSync } from "node:fs";
 import { pathToFileURL } from "node:url";
-import { spawn } from "node:child_process";
 import { parse } from "jsonc-parser";
+import { spawn } from "node:child_process";
 //#region src/host/load-user-env.ts
 /**
 * Loader for the user's `env.ts`.