🚀 Feature Request: Expand validateAdditionalProperties to more configuration types

[KianNH]

Describe the solution

The current usage of validateAdditionalProperties is only used for a subset of configuration fields, such as build or the top-level entries.

This means that you can use the following TOML and whilst it will publish with no warnings, route won't work and nor will you get warnings about that or the unknown i_dont_exist field.

name = "test-worker"
main = "src/index.ts"
compatibility_date = "2023-01-11"

[[kv_namespaces]]
binding = "KV"
id = ""
preview_id = ""

route = { pattern = "example.com/*", zone_name = "example.com" }

[[r2_buckets]]
binding = "R2"
bucket_name = ""
preview_bucket_name = ""

i_dont_exist = "foo"

Relevant file: https://github.com/cloudflare/wrangler2/blob/main/packages/wrangler/src/config/validation.ts

In my opinion, I don't see the downside to running it on everything other than unsafe bindings?

[mrbbot]

Hey! 👋 This seems like a good idea, especially given TOML format confusions. 👍

[jahands]

I ran into this today - turns out wrangler environments don't show the specific key that's invalid, making it harder to spot/figure out what was wrong:

▲ [WARNING] Processing wrangler.toml configuration:
- "env.staging" environment configuration

[CarmenPopoviciu]

as part of this fix we should also ensure that additional invalid fields defined at environment level will result in a warning as well. For example, top level additional fields currently do result in a warning, whereas environment-level ones don't:

[invalid_field]
name = "some name"

[env.staging.invalid_field]
name = "some staging name"

We should ensure that warning behaviour is on par across top-level/env config