wrangler-legacy

wrangler-legacy copied to clipboard

💡 Feature request

Overview and problem statement

Since Wrangler dev is now using a proxy through custom routes we need the ability to identify custom routes. Right now it requires a root base route (example.com), we need to be able to support other routes (dev.example.com) or at the very least use wrangler_dev true in the [dev] block.

I'm unable to use the latest version of Dev with subdomains (e.g. api.myworkersite.com). I'm not 100% sure, but I think this issue is the reason (calls to the subdomain are logged as calls to my root domain and return 301 redirects).

My project is using Workers for the static site (e.g. myworkerssite.com) and my site's API (e.g. api.myworkersite.com). Having Dev support subdomains is critical. Previously (before v1.11.0), I simply ran Dev for the API and Dev for the root (i.e. when developing, I ran two instances of Dev). Perhaps I'm missing something obvious here?

I, also, need to be able to test workers locally on custom subdomains.

@ashleymichal (or anyone else on the Wrangler team), is this something we might see land in the near future? It seems that v1.10.3 has stopped working for me for an unknown reason (dev compiles but always returns a 500 error), so not being able to upgrade (due to the latest lacking support for custom subdomains) has become a showstopper for me :(

Subdomains with Wrangler dev were working just fine before v1.11.0. Doesn't that make this a bug fix (since it's a regression) rather than an enhancement (i.e. making it a fairly high priority item)?

@TehShrike are custom subdomains working for you on v1.10.3 (the latest version before 1.11.0)?

We moved away from Wrangler for testing our worker that relies on subdomain routing. Mostly just hoping that we don't have to touch it until after this gets fixed

We moved away from Wrangler for testing our worker that relies on subdomain routing. Mostly just hoping that we don't have to touch it until after this gets fixed

Yeah, hopefully it's fixed soon.

FWIW: I did figure out that v1.10.3 does in fact still work with custom subdomains (somehow my installed version got bumped to Wrangler 1.11.0, which is why it stopped working).

Hey @yet-another-dev ! This does feel like a regression. Fundamentally this has to do with the fact that the version of wrangler dev that exists in 1.10.3 is running in our preview service (the same sandboxed process that you work in on cloudflareworkers.com and when you run wrangler preview), but v1.11.0 brings the process to the edge, giving you access to APIs that aren't supported in preview like the cache api. i imagine that we missed these cases when making that change. we've got fixes to wrangler dev on our roadmap in the near future, though, so i expect to put together a milestone for that in the coming month or so.

We are still experiencing this, I think it deserves classification as a bug - a feature that did work in v1.10.3 and does not in any further releases with no warning or documentation or alternatives supposed. Any idea when it may be addressed?

Any updates on this?

This was a regression, a bug in need of a fix, not a feature request. What's the hold up? This broke existing workflows (or is at least keeping them from staying up to date with Wrangler). This was issue opened nearly 6 months ago(!). Not good for developer loyalty! Grateful for an update (and super grateful for a bump in priority).

[brief aside] I have this sinking feeling that Cloudflare's "Page" feature and perhaps other related developments are taking priority and causing Wrangler to be neglected. Please prove me wrong and reassure me of my decision to build on top of Workers with Wrangler as a key component.

I have this sinking feeling that Cloudflare's "Page" feature and perhaps other related developments are taking priority and causing Wrangler to be neglected. Please prove me wrong and reassure me of my decision to build on top of Workers with Wrangler as a key component.

Hey @yet-another-dev. You're right, we screwed up on this, and on behalf of the team: I'm sorry.

As you hinted, the work we've been doing on Pages, Unbound, and Durable Objects has left wrangler without the love and attention it needs; no, deserves. There are no excuses and we must do better. Today, we have three engineering teams dedicated to the Workers platform (not hard to guess which three things they are prioritizing right now). Next month, we will have four, and wrangler is #1 on the priority list, literally. I look forward to rebuilding your trust.

As for this particular issue, we've identified the probable area of concern in Cloudflare's codebase, but it still needs more investigation because the original authors are no longer with us, so there's some catch-up to do.

I have this sinking feeling that Cloudflare's "Page" feature and perhaps other related developments are taking priority and causing Wrangler to be neglected. Please prove me wrong and reassure me of my decision to build on top of Workers with Wrangler as a key component.

Hey @yet-another-dev. You're right, we screwed up on this, and on behalf of the team: I'm sorry.

As you hinted, the work we've been doing on Pages, Unbound, and Durable Objects has left wrangler without the love and attention it needs; no, deserves. There are no excuses and we must do better. Today, we have three engineering teams dedicated to the Workers platform (not hard to guess which three things they are prioritizing right now). Next month, we will have four, and wrangler is #1 on the priority list, literally. I look forward to rebuilding your trust.

As for this particular issue, we've identified the probable area of concern in Cloudflare's codebase, but it still needs more investigation because the original authors are no longer with us, so there's some catch-up to do.

Thanks Ashcon! This is a much appreciated update.

Thank you @Electroid!

Next month, we will have four, and wrangler is #1 on the priority list, literally. I look forward to rebuilding your trust.

This is really good to hear. Thank you.

@Maxastuart, @yet-another-dev, @TehShrike, @kalepail -

Would you be able to test running wrangler dev -h ${YOUR_SUBDOMAIN} with your route subdomain?

If that provides the expected behavior, the next step for us is to pick up the route field in wrangler.toml, and apply it automatically. I just want to make sure this satisfies the need.

Also, it would be really helpful as we plan some additional work if you wouldn't mind sharing a bit about how you're using wrangler dev to test things.

• What's your process/workflow like?
  • are you using curl, a browser, something automated?
• Are you running integration tests from other things against your worker in wrangler dev mode?
• What are some of the routes you have in your wrangler.toml (anonymized is fine 😄 , just trying to cover all bases)

Sure @nilslice , great Q's!

Would you be able to test running wrangler dev -h ${YOUR_SUBDOMAIN} with your route subdomain?

Give me a little while, I'll try by EOD, just doing a little friday push to prod... 🙅 ❗ 🤯

• What's your process/workflow like?

I have it setup to push to and test on a tertiary worker on a tertiary subdomain:

• production is maps.***.com
• staging is stagingmaps.***.com
• development is devmaps.***.com
  • this is where we rebuild and push the worker to using wrangler publish while developing locally, luckily wrangler builds & publishes in a few seconds and if we're testing this we're testing changes in the worker code and don't have to rebuild the static site assets (we use worker sites in this worker too). I have to use one of our subdomains because our worker scripts communicate with our API and need CORS access, so not appropriate for ***.workers.dev.

• are you using curl, a browser, something automated?

To deploy or test? I use a browser while developing, curl in some github action scripts to test deployment went well, as well as a Cypress automated frontend test suite

• Are you running integration tests from other things against your worker in wrangler dev mode?

I will switch to this for the cypress tests depending on how well it works. Generally I like our tests running in staging to be full-production-replicas so I will run them against stagingmaps.***.com but any dev branch PR's github action tests can run on wrangler dev in an easier, less expensive and more secure containerized environment -- so thanks for fixing this.

• What are some of the routes you have in your wrangler.toml (anonymized is fine 😄 , just trying to cover all bases)

just one example, in one of multiple wrangler.tomls each called rootdomain.tld.wrangler.toml (anonymized):

[env.staging]
name = "blahblah-staging"
routes = [ "stagingmaps.website.com/claim/*", "stagingmaps.website.com/unclaim/*", "stagingmaps.website.com/update/*", "stagingmaps.website.com/claims" ]

and this is because the root of that domain is handled by another workers site worker and this one just handles those actions

(clearly I'm stalling my push >.<)

@Maxastuart - thanks for additional details, super helpful.

Give me a little while, I'll try by EOD, just doing a little friday push to prod...

Uh oh, breaking rule # 1 😆

Let me know once you've been able to test out your workflow using the -h flag & if it behaves as you would expect (based on prior behavior) - I appreciate your help!

@nilslice

Apologies for not getting this to you sooner! Hopefully it's not too late to be helpful.

---

Would you be able to test running wrangler dev -h ${YOUR_SUBDOMAIN} with your route subdomain?

When doing this, I get an authentication error:

--host provided, will run unauthenticated and upstream to provided host unauthenticated You have not provided your Cloudflare credentials.

I've tried going back through the steps prompted by wrangler login and wrangler config but am still getting the error.

Also, I think it's related to the authentication error, but Wrangler's also not reading my Worker secrets (locally defined, confirmed via wrangler secret list).

---

• What's your process/workflow like?

My use case is the following:

• My project has three subdomains (api.domain.com, account.domain.com, and www.domain.com)
• I use wrangler dev in development for running the api.domain.com to develop the endpoints locally
• The sites for each of the subdomains is 100% statically compiled and hosted by Workers Sites
• In development, I do not use wrangler dev to serve account.domain.com or www.domain.com (as I don't use any of the HTML rewrite features yet and don't use the KV store for runtime-specific data yet, other than environment variables – though eventually this may change and being able to serve these locally for development directly via wrangler dev would be a requirement)

---

• Are you running integration tests from other things against your worker in wrangler dev mode?

No.

---

• What are some of the routes you have in your wrangler.toml (anonymized is fine 😄 , just trying to cover all bases)

Relevant portion of my wrangler.toml (anonymized):

[env.development]
name = "mysite-api--dev"
route = "api-dev.mysite.com/*"
   [env.development.vars]
   ENVIRONMENT = 'development'

[env.production]
name = "mysite-api"
route = "api.mysite.com/*"
   [env.production.vars]
   ENVIRONMENT = 'production'

@nilslice tried wrangler dev -h, doesn't work for our case since we don't actually have a wrangler.toml - we have multiple so our files are renamed!

The way we're set up right now works because wrangler publish has a -c flag to specify which toml config file to use, but wrangler dev doesn't yet!

Let me know if you want to add that and have me try again, or want me to test in another way :)

I tried wrangler -dev -h as well, asks for credentials but still works as expected but in "logged out" mode.

My secret is also defined of course, so it's not picked up.

The way we're set up right now works because wrangler publish has a -c flag to specify which toml config file to use, but wrangler dev doesn't yet!

@Maxastuart - I believe this was fixed in the latest version. Are you on v1.17.0? If not, mind updating and trying again? Thanks!

@nilslice If it's helpful I can at least confirm, for me, the issue still persists (tested with 1.19.3) For reference, I hit this on multiple projects, so I'm pretty sure I'm having the same issue; it used to work before in an old version I used last year. Using zone TLD works fine.

Would you be able to test running wrangler dev -h ${YOUR_SUBDOMAIN} with your route subdomain?

I've tried this and get the same result as mentioned above:

⚠️ --host provided, will run unauthenticated and upstream to provided host unauthenticated

…so my scripts fail due to requiring an environment variable:

"ReferenceError: GH_PERSONAL_ACCESS_TOKEN_SECRET is not defined"

although this variable is defined and present in output for wrangler secret list.

I'm on wrangler 1.19.0

Seems highly related: https://github.com/cloudflare/wrangler/issues/1529

Wrangler v1 is now deprecated and support is only being provided for critical updates or security concerns. As such, we are closing this issue.

New versions of Wrangler are maintained in the workers-sdk repo. If you are running into a similar issue with wrangler v2, please report it in the workers-sdk repo. For more info about wrangler v1 deprecation, please check out our blog post.