[dev] RFC: add dev configuration to wrangler.toml

[EverlastingBugstopper]

Situation

Currently, wrangler dev takes some options when you start it up, namely --ip and --port. We're talking about adding --cors or something similar (maybe combo of --allowed-hosts and --allowed-headers?), and I imagine there are further bells/whistles we will want to add as more folks adopt wrangler dev as the way to develop Workers.

Problem

Right now there's no way for devs using wrangler dev to persist their development settings. If they want anything customized, they have to type out the arguments they use all the time and likely use .bash_history to remember what they do. This... isn't great. This problem gets even worse the more we extend the functionality of wrangler dev.

Solution

webpack-dev-server

webpack has TONS of customizable options for webpack-dev-server which can be defined in webpack.config.js. Documentation for that can be found here. A lot of the options they provide here can be defined in both webpack.config.js AND as a command line argument.

wrangler

I don't think we need to worry about being quite as extensible as webpack-dev-server, but their idea of allowing configuration in a persistent file is quite appealing to me. I imagine folks working together on a single project would likely want to have the ability to customize their dev setup and commit it to version control - especially for things like --allowed-hosts.

I think to start I would allow anything that is currently configurable for dev (besides --host for reasons) to be defined in [dev]. And for future features I'd allow any new extension to dev to be both a command line argument and configurable in wrangler.toml.

Not Doing

Another thing to note here is that some developer-specific configurations should not be committed to version control. The most common use case for this I can see is per-developer cloud credentials. Those concerns are separate and tracked here.

Open Questions

• should we do this at all?
• should [dev] be configurable for different environments, or should it be top level only?

[EverlastingBugstopper]

re: should [dev] be configurable for environments

I think it might make sense for different --allowed-hosts for different environments but generally it feels like something that should just be configured at the top level. Definitely interested in thoughts about this one.

[exvuma]

I understand the solution well enough, but I am confused on the problem. Do we have users using .bash-historycurrently? What commands are they copy and pasting?

If we do do this I definitely think it makes sense to keep this at level with other project building settings (e.g. site, type, webpack-config) so that'd be top level

[EverlastingBugstopper]

I just mean for remembering their configuration. Right now it's not too bad, but if we further extend the functionality of wrangler dev and add a bunch of flags, folks won't want to type out the same arguments every single time. When I mentioned bash_history I just meant pressing ⬆️ key repeatedly to find what they ran last time. Seems like configuration is a good way to solve that problem.

[ashleymichal]

i think yes we should do this, and it should be top level. likely you are generally running this in one environment, and occasionally switching to a "staging" or "production" environment for deployments, in which case passing flags is a suitable alternative for the latter. i think making it an environment level option introduces more confusion than it is worth.