Support multiple builds at the same time with Node.js adapter

Describe the problem

I have two projects: one provides auth and admin functionality with routes at /login, /register, etc., and the other provides an app using this auth including new routes. Both projects' svelte components and routes are compiled independently, with the intent to run them at the same time. The app/plugin (of which multiple can co-exist) can be swapped out in between different invocations/runs/instances of the server.

Unfortunatly, it appears that either Sveltekit or the Node.js adapter has no way to "fallthrough" to other code. Once a request is given to the adapter's handler, it will be responded too even when the handler doesn't have the page. While this makes sense when having a single handler, it fails when having two handlers.

For example, this is similar to my use case:

import { createServer } from 'node:http';
import { handler as mainHandler } from './path/to/main/handler.js';
import { plugins } from 'example/plugins';

const handlers = [mainHandler];

for (const plugin of plugins) {
	handlers.push(await import(plugin.handlerPath));
}

createServer((req, res) => {
	for (const handler of handlers) {
		function next(err) {
			// ... handles going to the next sveltekit handler
		}

		handler(req, res, next);
	}
});

Describe the proposed solution

A boolean option (e.g. fallthrough) that controls whether Sveltekit's Node.js adapter falls through (e.g. calling next() ) or not would fix the problem.

Alternatives considered

I've spent hours trying to work around the problem by attempting to isolate Sveltekit, however this failed.

The only way I've found to fix the issue is to compile in production.

Importance

would make my life easier

Additional Information

No response

Start with the Node.js adapter handler described in the issue and trace how it responds when a route is missing. Reproduce the case with two independently built handlers using the provided node:http pattern, then verify that the configured behavior reaches the next handler without breaking the default single-handler behavior.