[threepointone]

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.

[kjksf]

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

[threepointone]

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!

[protoduction]

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]

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

[threepointone]

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.

[yewenjie]

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

[threepointone]

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

[eloff]

Yeah, the esbuild experience is so much nicer.

[yewenjie]

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

[threepointone]

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!

[dkersten]

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.

[threepointone]

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!

[dkersten]

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.

[squaresmile]

- [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

[kentonv]

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.

[squaresmile]

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

[threepointone]

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

[pier25]

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

[vlovich123]

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

[threepointone]

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!

[Havoc]

>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

[threepointone]

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)

[Havoc]

>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

[pier25]

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.

[threepointone]

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

[pier25]

Thanks!

[robertlagrant]

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.

[threepointone]

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!

[robertlagrant]

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

[ignoramous]

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

[threepointone]

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