`wrangler types` command do not create KV Namespace types if they are nested in environments.

[Kjaer]

What versions & operating system are you using?

wrangler. 4.20.5, node.js 23.11.1, macos and linux (CI pipeline OS)

Please provide a link to a minimal reproduction

https://github.com/Kjaer/wrangler-kv-namespace-type-problem

Describe the Bug

I have following wrangler.toml file:

name = "my-worker"
main = "src/index.ts"
upload_source_maps = true
account_id = "xxxxxxxxxxxx"
compatibility_date = "2025-04-01"
compatibility_flags = ["nodejs_compat", "nodejs_compat_populate_process_env"]

[env.feature]
name = "my-worker-feature"

[[env.feature.kv_namespaces]]
binding = "MY_STORAGE_FEATURE"
id = "xxxxxxxxxxxx

[env.feature.vars]
DEPLOY_ENV = "feature"
SPACE_ID = "xxxxxxx"
ENVIRONMENT = "feature-environment"
FETCH_ENTRY_LIMIT = 1000
CACHE_DEFAULT_TTL_SECONDS = 3600

And I have similar 3 different environments in my wrangler.toml file too.

When I ran npx wrangler types it perfectly creates type definitions for environment variables. But it cannot create type definitions for KV Namespaces.

So I had to repeat KV Namespaces information on root level like this:

name = "my-worker"
main = "src/index.ts"
upload_source_maps = true
account_id = "xxxxxxxxxxxx"
compatibility_date = "2025-04-01"
compatibility_flags = ["nodejs_compat", "nodejs_compat_populate_process_env"]
[[kv_namespaces]]
binding = "MY_STORAGE_FEATURE"
id = "xxxxxxxxxxxx


[env.feature]
name = "my-worker-feature"

[[env.feature.kv_namespaces]]
binding = "MY_STORAGE_FEATURE"
id = "xxxxxxxxxxxx

[env.feature.vars]
DEPLOY_ENV = "feature"
SPACE_ID = "xxxxxxx"
ENVIRONMENT = "feature-environment"
FETCH_ENTRY_LIMIT = 1000
CACHE_DEFAULT_TTL_SECONDS = 3600

now npx wrangler types create type definitions for my KV namespaces. Eventhough I am getting warnings during deployment it still works. Yet this is not usual.

Please provide any relevant error logs

No response

[penalosa]

KV Namespaces are not shared between environments, so in general we recommend that if you have a KV namespace (etc..) in one environment it should also be in all other environments.

However, I agree that it's confusing that env vars are typed across environments while other bindings are not. We should fix that.

As a workaround, using wrangler types -e feature should give you the behaviour you want.

[Kjaer]

sweet! that'll do for now. I will adjust my CI deployment scripts passing environment for type generations and I think it will work. Thanks @penalosa.

I will create a new issue on the documentation, so we can add this wrangler types -e feature command to there, I hope everyone can benefit from it. Does that sound good?

[Kjaer]

Alright, I tried wrangler types -e feature but it didn't actually work. Unfortunately typechecks are failing. Because I have KV Namespace per environment and I get to decide on runtime which KV Namespace I need to use. So Typescript expects all possible KV Namespace name

I tried wrangler types -e feature,qa,prod and was hoping get all KV Namespace typedefinitions yet no luck.

I end up creating a dummy environment for only KV Namespaces as follows:

[env.storage]
[[env.storage.kv_namespaces]]
binding = "MY_STORAGE_FEATURE"
id = "xxxxx"

[[env.storage.kv_namespaces]]
binding = "MY_STORAGE_QA"
id = "xxxxx"

[[env.storage.kv_namespaces]]
binding = "MY_STORAGE_PROD"
id = "xxxxxx"

and now warnings are gone. Still a fix would be nice.

[mikechabot]

@Kjaer As I understand it, the binding name itself in the toml file is arbitrary, it's really the id that matters. For instance, I have 2 environments, each using a different KV, but in my toml file, I set the binding name as the same, whereas obviously the ids are different. I'm able to connect to each without issue. As a result, using wrangler types -e <env> is able to match across all environments.

[penalosa]

@Kjaer as @mikechabot says, I'd strongly recommend using the same binding name across different environments, with only the ID different

[timkelty]

What make this more confusing is vars seems to be treated differently than other non-inheritable keys.

E.g. for kv_namespaces, ratelimits, version_metadata, types will only be generated for the given environment, but vars seems to perform a merge of all environments, when an --env is not passed to the wrangler types command.

[petebacondarwin]

This issue has been fixed in PR #11893, which was merged on January 21, 2026. The wrangler types command now generates types for bindings from all environments by default.

Please update to wrangler 4.61.0 or later to get this fix. If you're still experiencing issues after updating, please open a new issue with reproduction steps.