Promote unstable_dev() to dev()

This issue will track the issues required to promote api/unstable_dev() to api/dev

• We should rewrite our local-mode tests to use unstable_dev:
  • https://github.com/cloudflare/wrangler2/issues/1419
  • this is blocked until we implement a react-free version of unstable_dev, as it doesn’t currently work in CI:
    • https://github.com/cloudflare/wrangler2/pull/1538
• https://github.com/cloudflare/wrangler2/issues/1756
• The API needs to export its types for consumers, tracked by:
  • https://github.com/cloudflare/wrangler2/issues/1387
• We need to finalise the types that dev uses for the options config:
  • https://github.com/cloudflare/wrangler2/issues/1418
• Stabilize unstable_dev’s options
  • https://github.com/cloudflare/wrangler2/issues/2344

[caass]

I feel like there should be a more defined goal for the librarification of wrangler – like is the point to export just the commands e.g. wrangler.dev, wrangler.kv.put? or will we also include things like running an authentication flow or parsing a wrangler.toml, which are not “commands” that wrangler runs but are potentially useful to people using wrangler as a library? I guess this is a scope question.

Once that’s decided, I think it also makes sense to define how exactly the commands we export are going to be defined – i think it would be nice to have all the commands follow a certain spec, like for example “every command returns an EventEmitter the user can listen to” or “every command takes as parameters its CLI arguments in camelCase instead ofkebab-case”.

I feel fairly strongly that we shouldn’t promote dev until these sorts of things are sorted, since any standardization/changes to the public facing…library…API…? would be breaking, and therefore require a new major release?

[lmcarreiro]

Thank you! Now my only dirty change into the cli.js is to expose the createTail. I’ll appreciate whenever you expose the unstable_tail API.