Node Adapter: "Dynamic require of "x" is not supported"

Describe the bug Unfortunately, I can’t provide much insight into what exactly causes this bug, but it’s been infuriating me for several hours now.

My app works great using both svelte-kit dev and svelte-kit preview. My app builds just fine: svelte-kit build outputs a beautiful build folder. Trying to run the site using node build/, however, blows up. I have no idea why this started – the library it’s complaining about worked about two weeks ago, and I haven’t updated the library. The library in question is also only referenced in hooks.ts and in endpoint files.

I can’t figure out how to reproduce this in a repo – there are so many variables at play here, and I don’t have enough knowledge to figure it out – but through exhaustively stepping through my commits to find exactly when the issue started, I’ve pinned it down to a specific commit for adapter-node: 0b780a61ef13996ac24be1aa74e5f70a447ca208. The commit before that works, any commit after doesn’t. This coincides with version 1.0.0-next.25 of adapter-node. I’ve also tried using 1.0.0-next.26, and that has the same error.

Unfortunately, I have some private info on the project I’m having this issue with, but I would be happy to hop on a call with somebody more knowledgable and show the error.

Logs

file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:28
  throw new Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "util" is not supported
    at __require (file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:28:9)
    at node_modules/azure-storage/lib/services/table/tableservice.js (file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:58812:17)
    at __require2 (file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:43:44)
    at node_modules/azure-storage/lib/azure-storage.js (file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:67878:24)
    at __require2 (file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:43:44)
    at file:///home/elliottjohnson/src/repos/test-svelte-app/build/index.js:88616:39
    at ModuleJob.run (internal/modules/esm/module_job.js:152:23)
    at async Loader.import (internal/modules/esm/loader.js:166:24)
    at async Object.loadESM (internal/process/esm_loader.js:68:5)

This is the line of the file causing the issue: var util = require('util');.

To Reproduce Not sure… I’m sure if I picked my app apart piece by piece I could narrow it down, but I’ve been at it for hours and I still don’t have a clue what actually causes this. I’ve gone so far as to completely purge the offending library (just for testing), and the same error will pop up for a new library.

Expected behavior My build to run!

System: OS: Linux 5.8 Pop!_OS 20.04 LTS CPU: (12) x64 AMD Ryzen 5 5600X 6-Core Processor Memory: 9.06 GB / 31.37 GB Container: Yes Shell: 5.0.17 - /bin/bash Binaries: Node: 14.16.1 - ~/.nvm/versions/node/v14.16.1/bin/node Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.1/bin/yarn npm: 7.15.0 - ~/.nvm/versions/node/v14.16.1/bin/npm Browsers: Chromium: 83.0.4103.116 Firefox: 89.0.1 npmPackages: @sveltejs/adapter-node: next => 1.0.0-next.26 @sveltejs/kit: next => 1.0.0-next.115 svelte: ^3.38.2 => 3.38.2

Severity Gamebreaking – the app doesn’t work after build!

[mylastore]

ok figure this out to, by moving most of the package in devDependencies to dependencies.

[tcc-sejohnson]

Aha! I made a new discovery – this might suggest that the issue I was seeing is more of a feature than a bug. Coming from the React world where we pretty much just throw everything into devDependencies and let the bundler take care of it, I was still using that strategy. After reading your PR, I figured the issue might be that my server-side deps being bundled. I moved @azure/msal-node and azure-storage to dependencies and it now builds and runs on 1.0.0-next.26.

This doesn’t explain why the issue doesn’t crop up in a minimal example when creating a new template app… but it at least fixes my problem.

If you’re happy with that explanation, feel free to close the issue and we can leave this here for any other hapless fools who try to bundle node-only libs in their devDependencies. If you’re not, I’d be happy to try to privately work with you to demonstrate and drill into the bug.