-
Notifications
You must be signed in to change notification settings - Fork 745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: experimental --node-compat
/ config.node_compat
#869
Conversation
🦋 Changeset detectedLatest commit: be5bd54 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.developers.workers.dev/runs/2259078223/npm-package-wrangler-869 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.developers.workers.dev/prs/869/npm-package-wrangler-869 Or you can use npx https://prerelease-registry.developers.workers.dev/runs/2259078223/npm-package-wrangler-869 dev path/to/script.js |
e48ed7d
to
70d29ba
Compare
🤔 In a future PR, I'm also tempted to replace node-fetch/isomorphic-fetch/undici by default with simple proxies to a regular fetch |
validateOptionalProperty( | ||
diagnostics, | ||
"", | ||
"node_compat", | ||
rawConfig.node_compat, | ||
"boolean" | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indirectly related to this PR, however, I was thinking we could add a optional messaging to the validation framework.
That would eliminate the need for things like
if (nodeCompat) {
logger.warn(
"Enabling node.js compatibility mode for builtins and globals. This is experimental and has serious tradeoffs. Please see https://github.com/ionic-team/rollup-plugin-node-polyfills/ for more details."
);
}
Is this to solve the Node 18 fetch bug? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
no, this is because those libs just don't work on Workers, and are meant as polyfills for fetch, which we provide natively anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
examples/node-app/src/index.js
Outdated
export default { | ||
async fetch() { | ||
// make sure path actually works | ||
return new Response(path.join("path/to", "some-file")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will this actually return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a string, 'path/to/some-file'. This project is simply a sanity test if and when you need to test node-compat. Honestly I might just delete this folder since it's not like we run it during CI or anything.
const nodeCompat = args.nodeCompat ?? config.node_compat; | ||
if (nodeCompat) { | ||
logger.warn( | ||
"Enabling node.js compatibility mode for builtins and globals. This is experimental and has serious tradeoffs. Please see https://github.com/ionic-team/rollup-plugin-node-polyfills/ for more details." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 👍🏻
This adds an experimental node.js compatibility mode. It can be enabled by adding `node_compat = true` in `wrangler.toml`, or by passing `--node-compat` as a command line arg for `dev`/`publish` commands. This is currently powered by `@esbuild-plugins/node-globals-polyfill` (which in itself is powered by `rollup-plugin-node-polyfills`). We'd previously added this, and then removed it because the quality of the polyfills isn't great. We're reintroducing it regardless so we can start getting feedback on its usage, and it sets up a foundation for replacing it with our own, hopefully better maintained polyfills. Of particular note, this means that what we promised in https://blog.cloudflare.com/announcing-stripe-support-in-workers/ now actually works. This patch also addresses some dependency issues, specifically leftover entries in `package-lock.json`.
Hey, just took a look at this PR and had one possible concern. I've been dealing some some people polyfilling using Eventually we figured out that I believe the way we finally resolved it was to disable the |
Interesting, I had no idea. Could you make a repo that reproduces the problem? I'm surprised to hear that the polyfill was overriding the global Crypto, is that what you're saying? I'm absolutely open to using better polyfills, or disabling ones that don't work right now, etc. |
Yup, I'd make an MRE ASAP! |
Alright, so it looks like this issue only occurs if the user imports This makes sense but it still might be worth disabling the For reference, repo is attached. https://github.com/isaac-mcfadyen/polyfill-wrangler-mre |
Thanks for digging into this, I appreciate it. There's no first class way to disable crypto simply in the poyfill we've used, so doing so will be a bit of effort. But we should definitely do it, sooner that later. I filed #875 to track it. Thanks again for bringing this to our attention! |
This adds an experimental node.js compatibility mode. It can be enabled by adding
node_compat = true
inwrangler.toml
, or by passing--node-compat
as a command line arg fordev
/publish
commands. This is currently powered by@esbuild-plugins/node-globals-polyfill
(which in itself is powered byrollup-plugin-node-polyfills
).We'd previously added this, and then removed it because the quality of the polyfills isn't great. We're reintroducing it regardless so we can start getting feedback on its usage, and it sets up a foundation for replacing it with our own, hopefully better maintained polyfills.
Of particular note, this means that what we promised in https://blog.cloudflare.com/announcing-stripe-support-in-workers/ now actually works.
This patch also addresses some dependency issues, specifically leftover entries in
package-lock.json
.