Provide ability to bundle dev dependencies for Node adapter

[Conduitry]

Describe the problem

Currently, the Node adapter will not bundle any external server side dependencies. This means that you need to make all of the dependencies you might need at runtime be prod dependencies. This differs from its (recent) previous behavior, and from Sapper's behavior, and from (I would argue) expected behavior.

Until now, it's been standard operating procedure to bundle as many of the server-side dependencies as possible, to reduce the deployed app size, parse time, and startup time. If there's some good reason to stop doing this, it should certainly at least be documented.

This issue may also well apply to other adapters (other than the static one), but I haven't tried to validate that.

Describe the proposed solution

I'm not entirely sure. It would be nice to be able to provide sensible default Vite configuration so that we have Vite do it, rather than do this in a separate esbuild step afterwards (either automatically or manually).

I don't know whether some different behavior from Vite would make this easier on our end, or whether this is something that Vite ought to change.

Below, I describe what I'm currently doing in userland to deal with this, but I'm not positive that this would have an equivalent in-framework analogue. (Do we have convenient access to the user's project's package.json?)

Alternatives considered

Currently, I have a vite.ssr.noExternal setting of process.env.NODE_ENV === "development" ? undefined : Object.keys(pkg.devDependencies) (where pkg is the parsed JSON from package.json) to force Vite to bundle all of my dev dependencies.

The check for development vs prod mode is there because I was having an issue using Object.keys(pkg.devDependencies) in dev mode that I haven't fully tracked down or tried to reproduce in a minimal repo, but which seem to stem from having a CJS-only dependency that Vite doesn't try to convert to ESM during dev mode.

Importance

would make my life easier

Additional Information

No response

[Karlinator]

So there used to be an esbuild step in adapter-node, which would bundle everything. It was removed in #2931.

@Rich-Harris was this an unintended side-effect of that? I can't see it mentioned in the PR or discussion.

[rpf3]

I ran into a similar issue to @Conduitry since upgrading and taking inspiration from this thread I added my package dependencies manually to the vite.ssr.noExternal config and got things working again. This definitely feels like a breaking change in how the Node adapter previously worked though.

A path forward would be a welcome discussion.

EDIT:

This was actually an issue with my build pipeline. We were copying the output directory of the Node adapter into a Docker image thinking it would provide a fully working application. I think what was going on is because certain packages were being externalized I needed to also copy the node_modules folder into the image.

[SomaticIT]

Hello,

I agree with @Conduitry that it could be interesting to have an option to bundle dev dependencies when using node adapter. The workaround is working well but an option would be simpler to use.

I think it should not create a single entry file (like before) but bundles only dev dependencies as suggested by Conduitry.
An option directly on svelte-kit that apply the above workaround may also be ok.

[Conduitry]

As of the latest versions of SvelteKit - with a separate vite.config.js - I now need to use conditional Vite config (https://vitejs.dev/config/#conditional-config) and specify an ssr.noExternal value of command === 'build' ? Object.keys(pkg.devDependencies) : undefined.

[benmccann]

Doing this makes the system harder to understand in my opinion because it makes dev different than prod (though perhaps that ship has sailed) and SvelteKit different from Vite. It also adds another way in which adapter-node is different from the rest (though the others are also different because they use esbuild).

If the adapters were Vite plugins (or could provide Vite plugins) then we could at least make this functionality available with a single option like bundleDependencies: boolean.