Skip to content

document multiple config flags in wrangler dev and types #22290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 13, 2025
Merged

document multiple config flags in wrangler dev and types #22290

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e92a0c6
document multiple config flags
emily-shen May 8, 2025
b65c248
fix type
emily-shen May 9, 2025
54b089b
also pages
emily-shen May 12, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions src/content/docs/workers/wrangler/commands.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -209,6 +209,9 @@ As of Wrangler v3.2.0, `wrangler dev` is supported by any Linux distributions pr
- The path to an entry point for your Worker. Only required if your [Wrangler configuration file](/workers/wrangler/configuration/) does not include a `main` key (for example, `main = "index.js"`).
- `--name` <Type text="string" /> <MetaInfo text="optional" />
- Name of the Worker.
- `--config`, `-c` <Type text="string[]" /> <MetaInfo text="optional" />
- Path(s) to [Wrangler configuration file](/workers/wrangler/configuration/). If not provided, Wrangler will use the nearest config file based on your current working directory.
- You can provide multiple configuration files to run multiple Workers in one dev session like this: `wrangler dev -c ./wrangler.toml -c ../other-worker/wrangler.toml`. The first config will be treated as the _primary_ Worker, which will be exposed over HTTP. The remaining config files will only be accessible via a service binding from the primary Worker.
- `--no-bundle` <Type text="boolean" /> <MetaInfo text="(default: false) optional" />
- Skip Wrangler's build steps. Particularly useful when using custom builds. Refer to [Bundling](https://developers.cloudflare.com/workers/wrangler/bundling/) for more information.
- `--env` <Type text="string" /> <MetaInfo text="optional" />
Expand Down Expand Up @@ -1982,8 +1985,13 @@ wrangler types [<PATH>] [OPTIONS]
- Control the types that Wrangler generates for `vars` bindings.
- If `true`, (the default) Wrangler generates literal and union types for bindings (e.g. `myVar: 'my dev variable' | 'my prod variable'`).
- If `false`, Wrangler generates generic types (e.g. `myVar: string`). This is useful when variables change frequently, especially when working across multiple environments.

<Render file="wrangler-commands/global-flags" product="workers" />
- `--config`, `-c` <Type text="string[]" /> <MetaInfo text="optional" />
- Path(s) to [Wrangler configuration file](/workers/wrangler/configuration/). If the Worker you are generating types for has service bindings or bindings to Durable Objects, you can also provide the paths to those configuration files so that the generated `Env` type will include RPC types. For example, given a Worker with a service binding, `wrangler types -c wrangler.toml -c ../bound-worker/wrangler.toml` will generate an `Env` type like this:
```ts
interface Env {
SERVICE_BINDING: Service<import("../bound-worker/src/index").Entrypoint>;
}
```

---

Expand Down