`preview_id` is optional, it'll use `id` for `wrangler dev` too if omitted - but this is only true f
preview_ididwrangler devwrangler dev--local flag
Cooooooooh yknow that's probably my issue
CI'll try that 1m
Cwelp. I guess the best solutions are often the simplest... If I omit
preview_id--localidpreview_id
Tlocal ignores the KV ids 
TIt's like it says, hosted locally
Ais there any way to get the correct request URL in a worker when using
wrangler devhttp://127.0.0.1:8787 , but from the worker code's perspective the request came from a <stuff>.workers.devevent.request.url.origin to send something back to the requester but since its pointing at workers.dev instead of localhost that doesnt work when running locallyAits not an error, it just gives me the wrong origin
Athe origin of the request is
127.0.0.1:8787<stuff>.workers.dev
Mdoes local mode work?
Ais that a wrangler 2 thing? still one wrangler 1.x
A1.19.7you're right, just havent gotten the time to update our stuff to support it yet
Abut in that case I wouldnt be able to send something back that points the original requester to the correct domain to send requests to. For example in this case I'm sending back a javascript bundle which has a parametrized "api domain" that it's being told to send requests to when the code is executed on the client. That host must match the domain the worker is accessible from since the worker is what responds to those requests
Athis works when the worker is deployed for real since the actual accessible URL matches the request's origin URL
Aunless there's a different way to "generically" obtain the URL of the worker
Ayeah ill probably look into upgrading, just not sure if this would be considered a difference of behaviour worthy of flagging for the regular
wrangler devi would expect the
event.request.urlit doesnt really matter where its actually "running"
Abut also it seems like that workers.dev url is not actually accessible so I guess its an internal URL?
Aactually i guess in a proxying scenario with something like nginx would the destination webserver see the original request origin
Aor does it show up on a header somewhere
Adifferent question: is there a way to have a custom build in wrangler 2 that also supports live-reloading?
Ajust using a custom webpack config, with wrangler 1 it would just autoreload automatically
Ayeah i saw this, but it doesn't appear to be working for me. It says the watch_dir defaults to the current working directory, does that mean I don't need to set it at all if that default is appropriate? or is it referring to the "cwd" setting, which I'd then need to set
Ai tried with neither of them set, and with both of them set to
'./'it doesnt seem to no
Ait doesnt seem to work even if i provide the absolute path to the folder
A
Athis and then a bunch of other envs listed later on with more env vars
Aand routes
KI don’t think it’s a requirement - allowed, but not required.
The docs use it in one place and then don’t in another - there’s no real structure to it since there’s nothing strict in the TOML spec
The docs use it in one place and then don’t in another - there’s no real structure to it since there’s nothing strict in the TOML spec
Ayeah the indenting doesnt matter
Ajust to clarify whats supposed to happen is if I change any file in the directory it should trigger a new run of my custom build command, then restart the miniflare server right
Ayeah we have a somewhat complicated build setup thats pulling in shared packages from our monorepo and doing some other stuff
A2.0.23
Athats actually the mode im using
Ai see
Amade one here https://github.com/cloudflare/wrangler2/issues/1566
GitHub
What version of Wrangler are you using? 2.0.23 What operating system are you using? Mac Describe the Bug I have a wrangler.toml file that looks like the following name = "js" acco...
S
I just noticed wrangler uses react
JThe way wrangler uses react is so interesting to me honestly - and one of the few reasons I’ve got more familiar with react recently haha. I’d love to read some more about the design decisions there in a post or something though I’m not sure it has mainstream appeal 
JOh very interesting 
WWell (not speaking for the wrangler team), Wrangler I think will always stay react but will be exposing APIs for others to build on top of.
So you could build a Vue version if you wanted or just build your own tooling and have Wrangler power that (much easier to maintain)
So you could build a Vue version if you wanted or just build your own tooling and have Wrangler power that (much easier to maintain)
Jvery cool
