Wrangler DX feedback
Hey devs, we'd love to hear your feedback on the @Wrangler CLI development experience, if you'd like to help us improve it, please share your feedback in this thread
7 Replies
I really dislike how long it takes for bindings to become usable in local mode. Take web rendering, it's still not supported in local mode. This wouldn't be as bad if there weren't also things that only supported local mode (WebGPU comes to mind, queues also didn't work in remote). Using browser rendering and queues in conjunction seems very common, and it was just impossible to develop for for quite a long time.
Things like vectorize are more understandable to be remote-only. It's a very new product, and it's internal so not trival to make work locally, I get that. Browser rendering, however, was announced nearly a year ago now and entered open beta in May. It's built on puppeteer, yet it still doesn't have local development. With the price we've seen off of BR, the cost of a messed up loop could skyrocket quickly.
Here's a few highlights from my experience with wrangler:
- Windows still feels like a second class target, with bugs often only surfacing in Windows
- Lack of release testing in general. This goes hand-in-hand with the first point, but so much of wrangler feels like it's released without people actually really testing those changes for more than a few minutes. The recent 3.13.0 release that has now been reverted is a good example of this - I filed 3 major issues with it after just using it on 2 projects for 5 minutes. The strategy around releases and testing really needs to be improved before more major refactors or features are added.
- Testing strategy in user-land is still sorely lacking.
unstable_dev is very much as the name suggests, unstable, and most other tutorials/solutions exist for miniflare 2, and aren't that compatible with wrangler 3.
- Compatibility date and types experience (especially with C3) is pretty rough. I filed https://github.com/cloudflare/workers-sdk/issues/3742 so won't go into this again.
- Echoing Zeg's point about local vs remote dev. It's very disjunct right now - you still can't wrangler dev --remote for example if you have a Queues consumer and get an obscure error. There are so many gotcha's and edge-cases that people run into all of the time, and some have been talked about above.
- node_compat vs compat flag nodejs_compat is a very disjunct experience. I filed https://github.com/cloudflare/workers-sdk/issues/4082, but this is now a blocker for even using some products like Hyperdrive if your project uses any nodejs_compat APIs.
- The way wrangler.toml kinda works but doesn't work with Pages dev confuses people all the time. https://github.com/cloudflare/workers-sdk/issues/3757
- Logging is finally being fixed which is awesome and very appreciated, but this being such a regression from 2.x for so very long was such a poor developer experience. https://github.com/cloudflare/workers-sdk/issues/3591
- Killing init in favor of C3 was a mistake. C3 is mostly okay now, but still not as powerful as init was with user-defined templates. workers-rs used to be able to just tell people to init a project with one simple npm command, now folks have to manually clone a sub-directory of the workers repository, just as one example.
- Repo maintenance and communication. This is a BIG one and needs to be really thought about. There are so many issues that people experience, get told to file an issue, and then 9 months or more later there's still no resolution or even communication - we see people regularly just give up and go deploy to Vercel where things work first time.
- There are community PRs from over a year ago that were told they'd be reviewed when there are some free cycles, but still just sit there with no communication. If you don't want to implement something, that's fine, but ghosting people does not create a positive developer community.- +1 for testing, we fall back to run the cli as
child_process which is also not stable and has a lot off caveats
- +1 for local & remote
- +1 for pages & wrangler.toml
- wrangler should expose more internal functions to use programmatically, e.g. config reading & parsing:https://github.com/cloudflare/workers-sdk/issues/3897
- wrangler should expose cli commands to use programmatically, e.g. I want to run wrangler commands from withing a custom file, something like: https://docs.astro.build/en/reference/cli-reference/#advanced-apis-experimentalMy real use cases / paint points:
- Tests. I'm using miniflare for testing now, hoping Wrangler will have something built in that just works with Vitest.
- Workers Analytics Engine. Missing from local development, so the code just throws "cannot read property...of undefined".
- Types.
wrangler types should probably generate wider types (i.e. strings instead of literals).. It should also take into account secrets (dev.vars).
- The fact that bindings are defined in wrangler.toml and secrets in dev.vars is a bit inconvenient. Why not use a de facto standard of .env files?
- Peogrammatic usage. Right now I just copied pieces of code straight from Wrangler source. Would be nice if those were exported as reusable functions instead 🙂The wrangler dev experience is pretty awesome. I started to deploy a few workers and it was really quick, simple to understand and straight forward. The pain started when I tried using pages since I needed a few static assets for the workers. The flow there is completely different, there is no wrangler.toml and there are many more subtle differences which are bad surprises like pages cannot run on wildcard rules like workers do. Please make pages exactly like workers (i can set bindings in a wrangler.toml for example) and all will be awesome. Thanks!
I really only need to be able to run pages locally with d1 bindings. so far this has NOT been working out for me. is there anyone else that have been able to make it work?
pages with d1 on deployment to cloudflare works as advertised but not on local only for development purposes.
There are a few commands that don't have --local options. For example,
C3 offers to deploy the empty project. Whilst this might seem a neat idea, it is likely to put the willies up most people who just want to try something out (locally). Better to just explain how to deploy when they get to that point. Improved SSL support, allowing an external key/cert to be specified - i.e. one that is trusted, rather than the wrangler one that isn't. wrangler.toml => .json (TOML just causes too much confusion IMHO). Better clarity on local pages dev and bindings. I spent ages trying to sort out sveltekit, and now have a solution, but others are likely to have issues. There's no explanation of what the
wrangler d1 create,wrangler d1 list, wrangler d1 delete all could have --local equivalents.
wrangler d1 execute has --local, but it isn't documented (https://developers.cloudflare.com/workers/wrangler/commands/#execute)
Having local and remote consistency increases confidence - who likes testing on production resources.
wrangler d1 migrations create - isn't clear how to create migrations locally. Shouldn't be dependent on a database name? (if so why?)
Wrangler occasionally forces authentication, even though it is operating entirely locally. This is confusing/worrying if you're trying to do something local.C3 offers to deploy the empty project. Whilst this might seem a neat idea, it is likely to put the willies up most people who just want to try something out (locally). Better to just explain how to deploy when they get to that point. Improved SSL support, allowing an external key/cert to be specified - i.e. one that is trusted, rather than the wrangler one that isn't. wrangler.toml => .json (TOML just causes too much confusion IMHO). Better clarity on local pages dev and bindings. I spent ages trying to sort out sveltekit, and now have a solution, but others are likely to have issues. There's no explanation of what the
wrangler pages dev -- cmd actually does, and whether it should really help.