-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
What versions & operating system are you using?
System:
OS: macOS 26.3
CPU: (14) arm64 Apple M3 Max
Memory: 998.92 MB / 36.00 GB
Shell: 5.9
Binaries:
Node: 22.20.0
npm: 10.9.3
npmPackages:
wrangler: 4.59.3 => 4.69.0
Please provide a link to a minimal reproduction
N/A
Describe the Bug
When using wrangler types with a static assets binding configured at the top level of wrangler.jsonc, the generated worker-configuration.d.ts file marks the ASSETS binding as optional (ASSETS?: Fetcher) instead of required (ASSETS: Fetcher).
Configuration in wrangler.jsonc
{
"assets": {
"directory": "./dist/client/",
"binding": "ASSETS"
},
"env": {
"dev": { ... },
"stage": { ... },
"prod": { ... }
}
}Command run:
wrangler types
Expected behavior:
According to the Cloudflare documentation, there should only be one collection of static assets defined. Since the assets field is defined at the top level and is inheritable by all environments, the generated types should reflect ASSETS as a required binding:
interface CloudflareEnv {
ASSETS: Fetcher;
// other bindings...
}Actual behavior:
The generated worker-configuration.d.ts marks ASSETS as optional:
interface CloudflareEnv {
ASSETS?: Fetcher;
// other bindings...
}This causes TypeScript errors when accessing env.ASSETS without optional chaining, even though the binding is always present at runtime.
Please provide any relevant error logs
No error during type generation, but the resulting types cause TypeScript to require optional chaining:
// This fails type checking even though ASSETS is always available
const response = await env.ASSETS.fetch(request);
// ~~~~~~~~~~
// Error: Object is possibly 'undefined'.
// Workaround required:
const response = await env.ASSETS!.fetch(request);
Metadata
Metadata
Assignees
Labels
Type
Projects
Status