Any news or progress you can share on
Any news or progress you can share on the typegen with
wrangler types becoming more cohesive with @types/node? All the time the typegen doesn't actually match runtime behaviour here and include real nodejs_compat types, it just causes more problems in my experience, especially when you introduce third party libs that still have to use workers-types.8 Replies
What is the actual issue? You can now use
@types/node alongside @cloudflare/workers-typesYou can, yes, but you get a whole bunch of types for things that don't actually work in the runtime because they're node types, and not actually nodejs_compat types. https://x.com/CherryJimbo/status/1927004843345956961 for context.
James Ross (@CherryJimbo)
@vladlykhonis @CloudflareDev Outside of `@types/node` for `nodejs_compat`, this is generally true. And then you get conflicts when libraries rely on specific `workers-types` things that might not exist with your specific flavour of runtime types.
But in my opinion, if it claims to generate types to match
X
Are you looking for
wrangler types --include-runtime to generate all the Node.js API types as well?that's one of the main promised benefits, that with the knowledge of the specific compat date/flags, the types generated can be more accurate
We did discuss that command doing this... let me see why it doesn't... Might be that we didn't have good types available from the polyfill bit of nodejs_compat?
yes, this would be the only compelling reason for typegen imo
I didn't realise but this has been discussed elsewhere here: https://discord.com/channels/595317990191398933/1352064976688250930/1352282358791012527
indeed yep