6 ms·
What I constantly ran into was disconnecting from the server I was connected to and wrangler not being able to handle that. At the time I had a somewhat spotty
by protoduction 5y ago
What I constantly ran into was disconnecting from the server I was connected to and wrangler not being able to handle that. At the time I had a somewhat spotty connection (nothing terrible), but it made wrangler dev very painful - so much so that I ended up writing my own node.js wrapper around it for local development. The lock-in to webpack also isn't great when I am nowadays accustomed to esbuild which is so much faster.
Happy to see miniflare now :)
- threepointone 5y agoOhhh I remember this too, I hated how it consistently dropped connections. A community member fixed this for us (here https://github.com/cloudflare/wrangler/pull/2008 https://github.com/cloudflare/wrangler/pull/2008) so that it transparently and automatically reconnects now and the experience has gotten so much better. And of course, miniflare reduces even the chance of that to zero :)
- threepointone 5y agoWe also don't have a lockin to webpack anymore (you can choose custom builds with the "javascript" type, which I admit is a little confusing). We're going to move away from even this dependency and make everything much faster and lighter, stay tuned.
- yewenjie 5y agoMaking the esbuild based starter the default one in the docs will be much more helpful.
- threepointone 5y agoHonestly, agreed. Lemme take this back to the team.
- eloff 5y agoYeah, the esbuild experience is so much nicer.
- yewenjie 5y agoYes, seconded. Also local changes take a couple of seconds to reflect - which is sometimes really annoying for the dev experience.
- threepointone 5y agoI've faced this too, where you'll save, then hit refresh, and it show the previous version; despite the fact that we "know" that the code is changed. SO we should be able to queue requests when we have a new version uploading (and of course, make the whole thing faster). Thanks for your feedback!