is it recommended calling directly, or via npx? (I know virtually zero about npm and npx)
is it recommended calling directly, or via npx?
(I know virtually zero about npm and npx)
(I know virtually zero about npm and npx)
Mscripts in jsons seem to use npx
Min .ts sorry
HCalling directly is what I do, though afaik
npm doesn't actually support that for arbitrary commands, so npx would probably be the next best thing.HI use
pnpm for arbitrary command execution using the locally installed package: pnpm wrangler deploy [whatever]MI have multiple folders (a worker, a pages app, functions) - so maybe I need to upgrade wrangler in all of them when updating?
MOK, for now I'm calling wrangler directly and it's solved that....now to fix broken Leptos app that won't deploy 
EHello, I'm thinking of using an API token because wrangler's oauth doesn't support multiple accounts.
How can I create an API token with privileges equivalent to wrangler login?
That is, an API token that has these permissions:
account:read
user:read
zone:read
workers:write
workers_kv:write
workers_routes:write
workers_scripts:write
workers_tail:read
d1:write
pages:write
ssl_certs:write
constellation:write
ai:write
queues:write
offline_access
How can I create an API token with privileges equivalent to wrangler login?
That is, an API token that has these permissions:
account:read
user:read
zone:read
workers:write
workers_kv:write
workers_routes:write
workers_scripts:write
workers_tail:read
d1:write
pages:write
ssl_certs:write
constellation:write
ai:write
queues:write
offline_access
Ldo you guys use the
satisfies in your workers?Li see it's present in some parts of the docs and not present in others
Lin other parts they use the types on the parameters instead
Jshort answer: a combo of both provides the best DX.
long answer: https://github.com/cloudflare/cloudflare-docs/pull/14007
long answer: https://github.com/cloudflare/cloudflare-docs/pull/14007
Lthe one you are using misses stuff
LYou could use
request: Request, env: EnvJYou don't need those with
satisfies ExportedHandler<Env> - the arguments are already typed
Lin some cases you also have extra stuff like here message batch
Lalso this is not needed?
JThat could be refactored to use
ExportedHandler - return type annotation too, yes
Lreturn type annotation?
Lpromise void u mean?
JAll you need is the return type like
: Promise<Response> for better DX, and then satisfies ExportedHandler<Env>;JYeah,
queue handlers don't need to return anything so: Promise<void> works wellLbut
satisfies operatore introduced in TypeScript 4.9 shouldn't just check that the function matches expect class?Lok but how does it make sure that
batch is of type MessageBatch?Linside the code i think you would miss some stuff
JExportedHandler takes other generic types, included one for MessageBatchJsatisfies covers most of the function. But the return type being explicit creates better errors for DX.JThat github PR I linked above and discussion that follows is a good reference.
JJExportedHandler<Env, MessageBatch> for exampleLdocs are messy
Lthey use half in one way, half in another way, another portion without anything lol
JFile an issue if you find any 
Many won't have type arguments though - they're JavaScript (not TypeScript) examples
Many won't have type arguments though - they're JavaScript (not TypeScript) examplesLokok so that's the new best way i see
JYes, the "best" and recommended way now is
satisfies - return type annotation. Like this: https://canary.discord.com/channels/595317990191398933/799437470004412476/1242537864642822245
Li see many docs also still explicitly put the
Env in the index.ts even tho now that's automatically generated in worker-configuration.d.tsLi guess that was also recent addition
JYeah that's super new, and not something I'm personally a fan of, but hey
JIt allows for good types generation via
wrangler types thoLis there a way to further improve this too?
JI'd add an explicit return type annotation on
fetch as : Promise<Response> so ts will catch if you ever accidentally return something elseJotherwise seems good
Lok
Dfun fact
Response | Promise<Response> is implied from implements DurableObject
VIs it possible to mimic worker routes in localhost with wrangler?
HAfaik no
THello.
I'm developing a worker that uploads files to R2. For local dev, is there a way to emulate S3 compatible endpoint that would serve/upload the files stored in the --persist-to dir that my worker is using?
I'm developing a worker that uploads files to R2. For local dev, is there a way to emulate S3 compatible endpoint that would serve/upload the files stored in the --persist-to dir that my worker is using?
HNot at the moment, no
Tthanks
KI ran into a really ODD problem that I don't think should happen. with the following wrangler toml
When running
If I change to:
When running
I thought the whole point of preview_database_id was for the remote use. Is this officially a bug? This seems very illogical.
When running
wrangler dev --remote the preview_database_id is used. Perfect! However, when running wrangler dev the preview_database_id is used. If I change to:
When running
wrangler dev the database_id is used.I thought the whole point of preview_database_id was for the remote use. Is this officially a bug? This seems very illogical.
