AAny plan to support config files for pages. This is a big issue for us.
Ayes, that is on the roadmap as part of our convergence work.
AGreat! That would help a lot. One for deployments, but two also for local dev & mocking of bindings. 
(aswell integration with other build tools)
(aswell integration with other build tools)Asome bindings are supported today for local Pages dev in like D1, but that's only for local dev
https://developers.cloudflare.com/d1/learning/local-development/
https://developers.cloudflare.com/d1/learning/local-development/
ACool! Yeah looking forward for full support. So we don't have to switch between dashboard & config file. Thx!
CYou can use the same command that you would with remote but add
CDo you want to add values to a local kv instance or run wrangler in dev mode?
CNot at my computer but it should be something like
CI might have gotten the part wrong but if you do then it should show the right command
CI don’t believe it matters. Wrangler should auto create it if it doesn’t exist
KREPOSTING - How do I get wrangler to NOT add this to every html response?
EThat should only happen when youre using
Etry explicit and if that doesnt work, whats your wrangler version and workers/pages setup?
KThis was as of 3.8.0 .. couldn't test in 3.9.0 because function bindings were not working.
MHello! After updating wrangler from v2 to v3 our no longer works and crashes with
One suggestion could be that wrangler v3 is not friends with PNP. So then, for some reason, running (after package manager installs it outside our project into home folder npm/npx cache), it seems to work but KV writes seem to crash with cryptic errors such as
and
Any idea what might be wrong with the move to v3?
One suggestion could be that wrangler v3 is not friends with PNP. So then, for some reason, running (after package manager installs it outside our project into home folder npm/npx cache), it seems to work but KV writes seem to crash with cryptic errors such as
and
Any idea what might be wrong with the move to v3?
ZIs there any way to tell wrangler to use a specific workerd executable?
J I think
JZAwesome, ty!
JI'm a Gray Cloud 
JWell... Purple in this case 
KNoooooooooooooo
CRunning
From what I understand, preview namespaces are not local, I checked on the dashboard and the value exists for the given key.
wrangler devpreview_idFrom what I understand, preview namespaces are not local, I checked on the dashboard and the value exists for the given key.
- Are preview namespaces what I am supposed to use locally?
- If not, is there something really local and how do I run that (I checked the docs but haven't found anything)
C
CI tried that and then it hangs
Not using writes it correctly to production
Not using writes it correctly to production
CSomething to do with the wrangler/miniflare dependencies perhaps?
CThat’s weird never had it hang before.
AIt shouldn't hang. If you're running into a consistent issue, please file a bug so we can take a closer look: https://github.com/cloudflare/workers-sdk/issues/new?assignees=&labels=bug&projects=&template=bug-template.yaml&title=%F0%9F%90%9B+BUG%3A
CFor context, yesterday it was complaining about not being the right binary (don't remember the detail), so I did
It's no longer complaining but maybe that caused some side effect? However, just installed all dependencies again, still hangs.
It's no longer complaining but maybe that caused some side effect? However, just installed all dependencies again, still hangs.
CGreat, thanks. Will file unless the binary thing sounds like some obvious issue
CI believe better-sqlite was removed because workerd now has it native.
Cright, using wrangler 3.10.0 now which hangs (was on an older version before), filing issue
CFollow up: turns out this is a Node issue.
For some reason it doesn't work with 20.5.1 but seems to play well with 20.7.0. Could possibly be related to me using NPM workspaces
For some reason it doesn't work with 20.5.1 but seems to play well with 20.7.0. Could possibly be related to me using NPM workspaces
CThis may be a better place to ask about dispatcher and running locally From my understanding wrangler local
Kwrangler 3.8.0 : D1 uses
for its sqlite storage
wrangler 3.9.0+ : D1 uses
<-- the UUID here, I have NO idea where it comes from and it is not in my wrangler.toml
It migrates my data from the old location to the new and destroys the old (NOT cool!)
.... all that aside ... I have 2 questions...
for its sqlite storage
wrangler 3.9.0+ : D1 uses
<-- the UUID here, I have NO idea where it comes from and it is not in my wrangler.toml
It migrates my data from the old location to the new and destroys the old (NOT cool!)
.... all that aside ... I have 2 questions...
- What exactly does that UUID reference?
- Was there a reason for this restructuring?
Ais the browser rendering api still in waitlist?