Add polyfill option to adapter-node

[ghostdevv]

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

This would close #7374 - I wasn't sure the best way to go about this but settled on this solution. Instead of building the polyfills into the handle.js before publishing adapter-node it will build a shims.js file which handle.js imports. If the polyfill option is false when the adapter code runs then it will empty the local copy of shims.js so it won't end up loading any polyfills

[benmccann]

Rather than add a new option I'd check the Node version and polyfill if less than Node 18. That removes the need for the user to learn about this option and set it appropriately.

Alternatively, we could just set the engines field to only allow Node 18 and greater on adapter-node 😆 I don't know if the others would want to release a new version with that change though as it's a bit more aggressive, but thought I'd at least mention the possibility 😉

[ghostdevv]

There are probably some weird reasons that people can't update to node 18 - my only concern with automatic detection would be if the user is building in a different node version than they run the code in

[benmccann]

Hmm. That's a good point I hadn't considered, but I bet we could do the check at runtime by inserting it here:

kit/packages/adapter-node/src/shims.js

Line 2 in bfa2b6e

installPolyfills();

[Conduitry]

We need to be careful trying to detect anything here - when we did #7668 before it caused #7673, because the bundled version of undici didn't support FormData. I don't know what Node version added support for that - or for any of the other features we might be using now. One of the benefits of having undici be a dependency of @sveltejs/kit is that we can bump it and know that we have the necessary features in adapters that need to polyfill these.

I'd probably prefer it to be an explicit opt-in by someone using adapter-node. 'I know what I'm doing, just let me use the pre-existing globals, whatever they may be.'

[benmccann]

Yeah, Node 18.11 would be needed:

kit/packages/kit/src/exports/node/polyfills.js

Line 24 in bfa2b6e

// TODO: remove this once we only support Node 18.11+ (the version multipart/form-data was added)

If we do make it an option, we should at least say in the docs to only use if if you're using Node 18.11 or newer. I'd still lean towards an automatic solution, but would be okay with either

[ghostdevv]

I added a note to the docs about the option and about Node 18.11

[Rich-Harris]

Another reason to prefer the option over automatic detection is that we can exclude the polyfill from the bundle. If it's based on detecting the version at runtime, the polyfill code still needs to be present even if it'll be unused.

Perhaps once we deem 18.11+ to be used widely enough we can flip the default to false, and provide a helpful error if we detect that the polyfill is necessary, but that would be a future breaking change.