This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
node_compat vs nodejs_compat developer experience #1856
Labels
You can continue the conversation there. Go to discussion →
Node.js compatibility via the
nodejs_compat
flag is getting better and better with Workers, and the docs at https://developers.cloudflare.com/workers/runtime-apis/nodejs/ are great.The compat is getting so good in fact that I'm starting to default to using Node.js implementations of things like
Buffer
andcrypto
because they're so much more ergonomic to work with.Unfortunately today, there are still a lot of libraries in the node ecosystem that
require('crypto')
, orrequire('tls')
and things which this compat flag doesn't solve, so the oldernode_compat
wrangler.toml
option often comes into play here. For some libraries, this works really well, such aspg
. Here's an anecodtal experience I had recently trying to play with Hyperdrive:This is not an uncommon experience, and people get confused about
node_compat
vsnodejs_compat
regularly.What is the long-term strategy here? Drop
node_compat
and work with library authors to ensure things work withnodejs_compat
? Offer some kind of interaction withworkerd
'snodeJsModule
type, with polyfills? Find a way for them both to work together? I very much expect folks to start using more and more node.js APIs, especially for things likecrypto
where the node.js implementations are just so much more ergonomic than WebCrypto, but if in doing so they lock themselves out of using libraries likepg
and others, that creates a pretty disjunct developer experience.This is somewhat similar to cloudflare/workers-sdk#4050.
The text was updated successfully, but these errors were encountered: