HNo, it is providing that return type directly
Umight as well be the same though tbh its not like generics guarentee the type 
HNot always, but they can
HDepends on what they are being used on
UI mean for this specific example it will never. But generics are nice for a lot of cases yes
HFor example, you can use a Zod type in a generic, and then you are guaranteed that they match
AYou would use something like Joi to validate the input JSON, then casting would be type safe
AAnd it makes nice user errors that you can return in your 400
DI'm running my worker locally with
Am I doing something wrong here?
yarn wrangler dev --node-compat however I still get the error there are no matching exports even though they should be supported according to the docs (https://developers.cloudflare.com/workers/runtime-apis/nodejs/crypto/)Am I doing something wrong here?
AI had a similar issue with
crypto.randomUUID()Aimport crypto from 'node:crypto'; does not workAThere is a default
crypto.randomUUID() and crypto.getRandomValues() in the Worker runtime, I ended up using that even though it may not be 100% node compatible
HDid you enable the
nodejs_compatWhat you are showing is
--node-compatIt has support for less stuff
H
DThat fixes my example code but I'm working with a third party library which no longer works when using
nodejs_compatcrypto instead of node:crypto. Is there some way I can make this third party library use the polyfill modules?HHRename
crypto to node:crypto, then mark it as externalDThat might work, but it seems a little weird to me that this is the best way to do it when
--node-compatMaybe? I generally just avoid deps that require Node, but I know that isn't feasible for everyone
HDon't remember the exact reasoning for it, but iirc it was something about Node's APIs not being JS-standard, so they wanted to scope them
HJust like how non-standard Cloudflare APIs that require an import are scoped
cloudflare:
KGiven there’s 4,521 dependents on the “crypto” lib on npm (which is built into Node now, yes) still 
KTIL they literally nuked it other than a deprecation README
KAnyways, there was work in Wrangler to make it automatically turn crypto -> node:crypto (and others) for you but that isn't done yet
DHow do I supply arguments like this to esbuild through wrangler?
DI'm not very familiar with TS build tools at all 
HYou have to install
esbuildThere are like 3 things you can configure on esbuild when using the
wrangler provided oneDThat sounds like it would need a lot of config to get it to work with cloudflare
DIt seems the library I'm using does have a browser version you can build yourself. I'll look into how to integrate that
Aanyone else not able to deploy? sees like wangler login isn't working. Gate way error 504
DOkay, this doesn't quite seem to work either. Is it possible it's trying to access browser APIs that CF Workers don't have access to?
DI'm not getting any build errors this time, it just doesn't work and throws warnings and tries to reconnect
KWhat package are you trying to use?
DI'm using gramjs, a Telegram client. It has both a node and browser version
DCF Workers might not be the best way to do this but I need something to automatically send a couple of telegram messages once per day
Aworking again
DDoes wasm binaries bundled using
Because my worker.js size is 940KiB and overall size including wasm is 2.3MiB after bundling but it throws the error
wrangler deployBecause my worker.js size is 940KiB and overall size including wasm is 2.3MiB after bundling but it throws the error
workers.api.error.script_too_largeKYes
Amhhh... if I am doing wrangler dev (and I dont do await on a htmlrewrite transform), it doesnt work. But it works deployed when doing return rewriter.transform(response);
AI should just do await then right?
AIn the docs there is no await so thats why I was confused!
KYou can return a Promise from an async function (i.e the
fetchyeah, I do that... but seems like when using locally (so without --remote) the htmlrewriter isn't running. Le tme create a sample project to show it
Aneed to find a nice way to create apis that can be consumed by workers. openapi seems so heavy these days.. tho maybe hono makes it nice
Ausing stuff like zodios/trpc and messing around with mono repos also an option i guess
BI'm having a hard time grasping the worker concept of environment variables. I'm using hono and I want to create a variable outside hono 'c.env' context. I don't understand Where this 'env' comes from.
