RFC: node_compat next steps

[penalosa]

Discussed in #1975

^{Originally posted by threepointone June 24, 2022}
We've landed preliminary support for node.js compatibility in 2.0, powered by @esbuild-plugins/node-modules-polyfill/@esbuild-plugins/node-globals-polyfill. We can also auto detect usage of node built-ins, and suggest to the user to add node_compat = true to their wrangler.toml. This was a good start. Follow up items.

• The plugins we're using don't provide much in terms of customisation or control. We should replace the plugin with one we own "in house", so to speak. This will let us have control on which polyfills we enable, and how they're configured (eg: this will solve 🐛 BUG: Cannot use node builtin polyfill "crypto" #1047)
• The polyfills used by those packages (https://www.npmjs.com/package/rollup-plugin-node-polyfills) are old and not maintained, we should replace them with ones that are maintained better (options Project Not Maintained ionic-team/rollup-plugin-node-polyfills#28)
• That is still temporary tho, we should also start planning for using our own polyfills that fit well in the Workers environment. As an example, the community polyfills for http are built on XMLHTTPRequest, which isn't available in Workers. We'd need to rebuild it with fetch (if that's feasible)
• A long term plan might be to also provide runtime support for node compatibility; i.e., for the Workers runtime itself to provide require-able/import-able polyfills for node built-ins and globals.
• There's also an immediate opportunity to provide "anti" polyfills for fetch polyfills as described in feat: automatically replace fetch polyfills (isomorphic-fetch, node-fetch, unidici etc) with shims #1011.

cc @jasnell who I bet would be interested.

[chrisspiegl]

Is there any news on this?
I just ran into an issue where I tried using node_compat mode and it threw the error that XMLHTTPRequest was missing?
Found this issue but it's closed?

I am setup with wrangler 2.6.2