Miniflare – Simulator for developing and testing Cloudflare Workers | Hacker News Reader

Miniflare – Simulator for developing and testing Cloudflare Workers

github.com

124 pointsmadmax10850 comments

This is great because quite frankly wrangler dev is just terrible.

I've had nothing but problems with it.

What problems have you had?

- Incomprehensible errors. Like you have a undefined var and the worker just breaks and doesn't tell you what's happening.

- Terrible console.log() messages. I had to resort to using JSON.stringify for anything other than primitive values.

- Timeout errors when using wrangler dev on workers that work perfectly when deployed.

- Wrangler dev just crashing frequently or being super slow at reloading the worker.

Errors - We're getting better at this. You can now use `--inspect` and use chrome devtools which should log proper exceptions (details to setup https://blog.cloudflare.com/profiling-your-workers-with-wran...) Console.logs - same as above! Real devtools, interactive and everything. Timeouts and crashes - This should be better now, timeouts and sessions expires now transparently heal and restart, so you shouldn't face errors (Please file an issue if you see different!)

Overall we're working hard on making this experience better, please feel free to file issues if you see anything that's not expected. Thank you!

No kidding. Wrangler was so bad I stopped using Workers altogether.

It’s gotten better. Wrangler tail works consistently now.

Yeah, we recently made improvements so `wrangler tail` works without falling over, and we also show logs directly in the dashboard now (https://blog.cloudflare.com/introducing-workers-dashboard-lo...) More improvements coming, I promise.

That bad, huh :( But I hear you. I'm working on making this better right now, I'd be happy to hear any complaints you have, and I hope we can get you back.

I'd love to help but it's been so long that I don't remember what exactly it was I was struggling with. Thanks for the offer, though!

Same... I'm only using Workers for a very specific use case but otherwise I just prefer developing for any other serverless platform.

Workers are great once they are deployed, but the DX is abismal...

I find wrangler really decent to work with, it's pretty minimalist but does everything I need

What kind of issues did you have ?

Hi there! I'm on the team, and we're going to invest a bunch of time and effort on making this experience much better. Happy to hear any specific feedback if you'd like, and I'll prioritise it. Feel free to reply here, or DM me on twitter @threepointone.

Stay tuned, things should get better soon.

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 :)

Ohhh 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) 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 :)

We 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.

Making the esbuild based starter the default one in the docs will be much more helpful.

Honestly, agreed. Lemme take this back to the team.

Yeah, the esbuild experience is so much nicer.

Yes, seconded. Also local changes take a couple of seconds to reflect - which is sometimes really annoying for the dev experience.

I'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!

- [Not relevant] There's this limitation about fetching host+port [0] in the worker. It works fine in wrangler dev but doesn't work on Cloudflare worker. I don't mind that it's a limitation of the platform but there should be documentation and wranlger dev should be consistent with the actual worker.

- It's not relevant now but I couldn't figure out how to connect cloudflared with wrangler tail on windows. Wrangler tail points to the cloudflared docs but the cloudflared docs doesn't mention wrangler at all. I was pretty lost for what to do.

- [Not relevant] I haven't investigated this properly but Promise.then.catch doesn't seem to work? async/await works though.

- I'm pretty sure URL.createObjectURL in this example [1] doesn't work on the worker.

- Wrangler dev doesn't have the request.cf object. I see why but a dummy one would be cool.

None is deal-breaker but they wear you down when you walk through the documentation.

[0] https://community.cloudflare.com/t/fetch-in-worker-strips-po...

[1] https://developers.cloudflare.com/workers/examples/read-post

This is amazing feedback, thank you very much! I'm going to work on each of these; but quickly - we definitely shouldn't have something that works in `wrangler dev` but not in the platform, and we should warn/error on that, our docs shouldn't have examples that don't work :facepalm:, and we should be spec compliant where we can. Thank you so much!

Hi squaresmile,

Thanks for the feedback!

It sounds like you may be thinking of `wrangler preview`, not `wrangler dev`. `wrangler preview` runs the worker on a service that operates outside Cloudflare infrastructure, so a lot of things aren't realistic, like support for host+port and request.cf. `wrangler dev` runs the worker inside the real Cloudflare stack on the real edge, which should solve those problems. Our plan is to sunset `wrangler preview` in favor of `wrangler dev`.

> It's not relevant now but I couldn't figure out how to connect cloudflared with wrangler tail on windows.

Good news, this has been fixed recently -- `wrangler tail` no longer requires `cloudflared`.

> - I haven't investigated this properly but Promise.then.catch doesn't seem to work? async/await works though.

Promises are implemented inside V8, so they should work exactly the same on Workers as in Chrome and Node. I'd love to see an example of what's not working if you have one.

> - I'm pretty sure URL.createObjectURL in this example [1] doesn't work on the worker.

This is indeed an API we don't support, and realistically we probably can't support. I'd be interested to understand your use case for this.

> dev/preview

Ah sorry, I was confusing stuffs. It wasn't even wrangler preview, it was the web editor on the worker website.

> cloudflared

Yep, I noticed that update. I couldn't have updated wrangler faster.

> Promise.then

I'm sorry again. False alarm. It's me not understanding when things get executed.

> URL.createObjectURL

I don't really have a use case for it. It was mostly me seeing the example code being reasonable, copied it and was surprised it didn't work.

We should definitely not have examples on the docs that don't actually work. I'll fix this.

Do you accept PRs on the docs (at least for the examples)?

Yes. https://github.com/cloudflare/cloudflare-docs/

Also, every page has an "Edit on Github" link so you can go straight to the page you're seeing (in this case - https://github.com/cloudflare/cloudflare-docs/blob/productio...)

I personally never really figured out how to get it working properly when I was using it. I resorted to just returning data as the response page to see what I was debugging and testing "in production". This was a few months ago, so I don't remember the details of what didn't work or why, just that I gave up on it altogether.

I'm so sorry you had to deal with that. We're working on removing a lot of friction from the onboarding process, and making it easier to introspect what everything's doing. Thank you for your feedback!

That's good to hear! I still use and like cloudflare workers, but at the time, earlier this year, the debugging experience was still a bit rough. So if that's improving, then I'm happy.

For example, wrangler dev just stopped working on all my current workers. All requests return a timeout error.

Only workers created with wrangler generate work.

I opened this issue and never received an answer:

https://github.com/cloudflare/wrangler/issues/2077

I closed it because wrangler dev still works with generate, so I assumed it was a problem on my end.

It still sucks that it just stopped working for no reason.

That sounds like a terrible experience. I've reopened your issue and assigned it to myself, will investigate it soon.

Thanks!

Will miniflare eventually find its way into wrangler and/or replace wrangler-dev?

No specifics to share just yet, but we're definitely going to integrate wrangler more deeply with miniflare.

Here are things I ran into.

`wrangler login` doesn't work if I'm not already logged in to CloudFlare website. If I have to login first, it doesn't do whatever necessary redirect it should do so most of the time I have to run `wrangler login` twice.

`wrangler dev` is slow.

`wrangler dev` requires root domain. https://github.com/cloudflare/wrangler/issues/1529

I also feel that the interaction between DNS settings and workers is under-documented, probably because it crosses responsibility of two different teams.

For example, it took me way too long to figure out that if I have a workers-only website for foo.bar.org, I have to put dummy DNS entry for foo.bar.org

Frankly, despite reading wrangler docs multiple times, I don't think I fully understand the interactions between what's in the DNS, what's in the workers route and further more if you add pages to the mix.

Docs should explicitly spell out DNS / routes setup for most common scenarios like: 1) workers-only site (no proxying to any other server) 2) workers in front of a proxied website

Workers should be seamlessly integrated with pages i.e. pages should just automatically recognize and use workers-site/ directory on deploy.

I don't think setting up pages automatically configures DNS settings for its domain, which it obviously should (might be mis-remembering).

Great feedback! Some quick replies -

- > `wrangler login` doesn't work if I'm not already logged in to CloudFlare website This should be fixed in our last release!

- `wrangler dev` is slow. Agreed. We're working on making it faster, but miniflare is a great option for the fastest dev experience at the moment.

- Regarding DNS/domains/Workers, this is all great feedback. We should be making this more painless/intuitive. We'll work on it!

>Hi there! I'm on the team

Could you add a validate switch? Something I can integate into a CI pipeline that basically takes a look at whether it is a valid CF worker. Obviously running a linter over it already but presumably there are CF specific checks that could be added. Thanks

Could you share more detail about your usecase? What kind of checks are you looking for? I'd be happy to have a look at that (and presumably if we could do it before it gets uploaded, that would be great)

>What kind of checks are you looking for?

A very basic rudementary static code analysis that can check whether this is a valid CF worker configuration.

>Could you share more detail about your usecase?

In a CI configuration like gitlab CI. e.g. Currently I'm using an incredibly hacky setup that loads the function into miniflare locally, hits then endpoint with a curl and checks that it comes back with 200 HTTP.

If yes then assumption is that it's sound & next stage of CI can actually deploy the function.

Not super high priority though - please prioritise other requests above this since I've already got a working duct tape fix for my problem

My thing, which I asked about in the Discord as well, was how to line up environments for local Dev, cloud staging (e.g. a preview from a pull request) and production, across workers, pages and kv. Having a preview mode is fine but I struggled to know what should map to what in a consistently configured way, for a monorepo setup that's updating everything in the same PR.

Yeah agreed, this is pretty ad-hoc right now, smeared across different commands and config. We're working on a better solution, will share more details when we have something. Thank you for your feedback!

It's a pleasure. I'm a big fan; that's just one of a couple of things that I'm struggling with. The other is, "this smells like extremely well-made proprietary software that I will have to hope a Cloudflare product manager never deprecates if I commit to it".

I use CFW with Pulumi, but it doesn't offer local dev.

Hooray, my dream came true: https://news.ycombinator.com/item?id=27748154

I'm very happy about this, an official support to run Workers locally. I invested some of my personal time to get this tool, I submitted a patch on a community project (since Cloudflare wasn't officially supporting this). I think it was a very important missing piece for me to consider Workers a serious development tool.

https://github.com/gja/cloudflare-worker-local/commit/ce6004...

Wow, if I understand this correctly... this was posted on HN this morning, and by the afternoon it's already in the official cloudflare GH org?

That reflects extremely well both on this repo as well as cloudflare.

It was first posted on HN 3 months ago[1], and moved to the cloudflare org a day ago[2].

[1]: https://news.ycombinator.com/item?id=27736706

[2]: https://twitter.com/_mrbbot/status/1441143456106094595

Fun fact, that post 3 months ago was what got us folks at cloudflare in touch with the author, who then interned with us for 2 months (today was his last day!)

Reply on news.ycombinator.com