🚀 Feature Request: improve the wrangler.toml config experience

[IgorMinar]

Describe the solution

A feedback that often comes up in various discussions is that the toml config file is not ergonomic, error-prone, and generally unpleasant to use.

There are at least three different root causes behind this pain:

• there are inherent issues specific to toml syntax/spec (sample writeup of common issues)
• we provide only limited validation of the wrangler.toml file (see example file that passes validation when it shouldn't)
• most Web developers are not familiar with the toml format, json (and even yaml) are used much more commonly

We could improve the validation of the toml file (interesting schema-based validator: https://json-schema-everywhere.github.io/toml), but we might as well consider using alternative format altogether.

One alternative to consider is JSON with comments. This format is very popular format (used by TypeScript, Angular, and many others), has great tooling support for validation, formatting, syntax highlighting, docs generation.

In order to smooth out the transition if we do adopt an alternative format, we should also make it easy for people to convert the existing toml file to the new format. This could be a built-in functionality of Wrangler — we could for example automatically prompt the dev and offer the config file to be converted if they are still using toml.

I've seen some people ask for js based config language. While there is a space for imperative Wrangler API for general configuration, it is generally much more preferable to stick with declarative languages for configuration because those are more suitable for long-term evolution (via automated config transformation) and are significantly easier to integrate with other tooling (like IDEs) which otherwise would need to execute untrusted code in order to read the config.

---

example of a toml file that passes validation, and critical config property to be ignored during deployment:

name = "test"
main = "src/index.ts"

[[durable_objects.bindings]]
name = "test"
class_name = "Test"

[[migrations]]
tag = "v1"
new_classes = ["Test"]

compatibility_date = "2022-05-16"

The compatibility_date property is ignored when it shouldn't be.

[threepointone]

Yeah, we want to change the format (or rather, accept multiple formats), we just haven't gotten around to it yet. Of note with this specific example tho, is that we do log a warning for a missing compatibility_date, so it's not completely silent. We were missing validation for unexpected fields in migrations, fix at #1166

[IgorMinar]

Supporting multiple formats often becomes a big headache because of increased maintenance and support cost (bugs, extra design time needed for new config keys, extra documentation needed). If we could just land on a single format (or temporarily, during a migration, support two formats) then that would be preferable.

[penalosa]

Closing in favour of #1951