adapter-node 5.5.6: `manualChunks` hoists an unresolvable conditional `require` into the boot entry, so the server dies with ERR_MODULE_NOT_FOUND

[Stadly]

Describe the bug

Starting with @sveltejs/adapter-node@5.5.6, a production build can contain a top-level static import of a package that is not installed anywhere, in build/instrumentation.server.js — the very first thing build/index.js imports. The server never starts:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@babel/preset-typescript' imported from /app/build/instrumentation.server.js
    at Object.getPackageJSONURL (node:internal/modules/package_json_reader:301:9)
    at packageResolve (node:internal/modules/esm/resolve:768:81)

The offending line in the emitted bundle is a bare side-effect import:

// build/instrumentation.server.js
import '@babel/preset-typescript/package.json';

Nothing in the dependency tree installs @babel/preset-typescript. The import comes from a require that CommonJS code guards behind a catch block and never reaches at runtime — @rollup/plugin-commonjs hoists it to a static ESM import, tree-shaking then removes the surrounding code but keeps the now-dangling side-effect import, and nodeResolve leaves it external because it cannot resolve it. Because adapter 5.5.5 moved this file to the build root and put it on the boot path, an import that was previously inert now kills the process before it listens.

This took down one of our deployments: the image builds fine, the container starts, runs its migrations, and then exits on the trace above with nothing else logged.

Reproduction

Minimal app, verified from scratch. Four files plus a package.json:

package.json

{
  "name": "repro-adapter-node-babel",
  "private": true,
  "type": "module",
  "scripts": { "build": "vite build" },
  "overrides": { "@sentry/vite-plugin": "5.3.0" },
  "devDependencies": {
    "@sentry/sveltekit": "10.63.0",
    "@sveltejs/adapter-node": "5.5.6",
    "@sveltejs/kit": "2.70.2",
    "@sveltejs/vite-plugin-svelte": "^7.2.0",
    "svelte": "^5.56.4",
    "vite": "^8.1.3"
  }
}

svelte.config.js

import adapter from "@sveltejs/adapter-node";

export default {
  kit: {
    adapter: adapter(),
    experimental: { instrumentation: { server: true } },
  },
};

vite.config.js

import { sveltekit } from "@sveltejs/kit/vite";

export default { plugins: [sveltekit()] };

src/instrumentation.server.js

import * as Sentry from "@sentry/sveltekit";

if (process.env.SENTRY_ENABLED === "true") {
  Sentry.init({ dsn: process.env.SENTRY_DSN });
}

Plus a trivial src/app.html and src/routes/+page.svelte. Then:

npm install
npx vite build
grep -n "preset-typescript" build/instrumentation.server.js
# 22:import '@babel/preset-typescript/package.json';

node build/index.js
# Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@babel/preset-typescript'
#   imported from .../build/instrumentation.server.js

The @sentry/vite-plugin override is only there to hold the transitive dependency at the version that still pulls @babel/core (5.3.0, via @sentry/bundler-plugin-core); 5.4.0 swapped that out, which incidentally hides the bug. Sentry is not special here — any dependency reachable from instrumentation.server.js that contains a guarded require of an uninstalled package will do.

Bisect

Same app, same lockfile, only the adapter version varying:

adapter-node	instrumentation output path	files with the dangling import	node build/index.js
5.5.4	build/server/instrumentation.server.js	0	boots
5.5.5	build/instrumentation.server.js	0	boots
5.5.6	build/instrumentation.server.js	2	ERR_MODULE_NOT_FOUND
5.5.7	build/instrumentation.server.js	2	ERR_MODULE_NOT_FOUND

So it is 5.5.6, not the 5.5.5 restructure, that introduces the dangling import. 5.5.5 (#16069) moved the file to the build root and onto the boot path; 5.5.6 added the manualChunks option in #16115 — the fix for the #16092 top-level-await deadlock:

// packages/adapter-node/index.js
manualChunks(id) {
    if (id.startsWith(server)) {
        return id.slice(server_path_length);
    }
}

Forcing every module under the Vite server directory into its own chunk changes where rollup places external imports, and the dangling side-effect import ends up hoisted into the entry chunks — including the one the server boots from.

This is the whole of the functional 5.5.5 → 5.5.6 diff: the only other change in index.js is extracting ${tmp}/entries into an entries local. So manualChunks is not merely correlated with the regression, it is the sole candidate.

Why the import exists at all

The chain in the repro is instrumentation.server.js → @sentry/sveltekit (whose server entry re-exports the sentrySvelteKit Vite plugin) → @sentry/vite-plugin → @sentry/bundler-plugin-core → @babel/core. Inside Babel:

// @babel/core/lib/config/files/module-types.js:165
} catch (error) {
    const packageJson = require("@babel/preset-typescript/package.json");
    if (_semver().lt(packageJson.version, "7.21.4")) { ... }
    throw error;
}

@babel/core declares @babel/preset-typescript neither as a dependency nor as a peer — it is a soft runtime lookup that is legitimately absent, which is why the require is guarded. The adapter marks only pkg.dependencies as external, so everything else is bundled, and this guarded require becomes a hard static dependency of the boot entry.

Worth noting the emitted import targets a .json file with no import attribute, so even installing @babel/preset-typescript would not make it loadable — under Node ESM it then fails with ERR_IMPORT_ATTRIBUTE_MISSING: Module ... needs an import attribute of "type: json" (verified separately). There is no user-side dependency fix available; the emitted import is invalid regardless of what is installed.

Suggested directions

1. Don't let unresolved externals reach the instrumentation entry. Since it is --imported before anything else, an unresolvable specifier there is always fatal. Failing the build (or warning loudly) when the instrumentation chunk has an external that nodeResolve could not resolve would turn a silent production crash into a build error.
2. Revisit the manualChunks shape from fix: avoid circular dependency #16115. The deadlock fix is doing more than retaining file structure — it is changing external-import placement. Narrowing it, or excluding the instrumentation entry from it, may address both.
3. test(adapter-node): boot the built output when instrumentation.server.js is present #16305 would have caught this. It adds an adapter-node test that actually boots build/index.js with an instrumentation file present; that gap is exactly why a fatal boot regression shipped in a patch release. Landing a boot test looks more valuable than any single fix here.

Related

• fix: bundle entrypoints alongside app code #16069 — moved the instrumentation file to the build root (5.5.5)
• adapter-node 5.5.5: top-level await deadlock at server init when a hooks-graph module imports $env/dynamic/private (regression from #16069) #16092 / fix: avoid circular dependency #16115 — the top-level-await deadlock and its manualChunks fix (5.5.6), which is what this regression rides in on
• test(adapter-node): boot the built output when instrumentation.server.js is present #16305 — proposed adapter-node boot test with instrumentation present
• fix: externalize @opentelemetry/api to prevent chunk colocation #16302 — externalizing @opentelemetry/api; same "instrumentation entry gets contaminated by shared chunking" family

Severity

Silent and total: the build succeeds, the image builds, and the container exits at boot. Nothing in the build output flags an external that resolves nowhere.

System info

@sveltejs/kit: 2.70.2
@sveltejs/adapter-node: 5.5.6 / 5.5.7 (5.5.4, 5.5.5 unaffected)
vite: 8.1.3
svelte: 5.56.4
node: v24.17.0
npm: 11.13.0
OS: Linux 6.6.87.2 (WSL2)

[Stadly]

(Edited to correct a branch mix-up: an earlier version of this comment said "main is not affected". That was wrong — I had tested the version-3 line. main is the 5.5.x line and is affected. Corrected below.)

I dug into the mechanism further, and the conclusion moved: the root cause is in @rollup/plugin-commonjs, not in adapter-node. Two corrections to my original report, and two PRs.

The require is converted because a catch clause isn't treated as guarded

ignoreTryCatch defaults to true, so a require of a possibly-uninstalled external is meant to be left alone rather than hoisted. But the guard window is computed from the try block:

case 'TryStatement':
  if (currentTryBlockEnd === null) {
    currentTryBlockEnd = node.block.end;   // ← try block only
  }

A require in the catch clause starts after node.block.end, so it falls outside the window and is converted like any unguarded require. That's why Babel's sibling require('@babel/preset-typescript') — in the try block, a few lines away — is already left alone today, while only the /package.json one in the catch leaks.

Fix proposed as rollup/plugins#2018 (292 tests passing, new fixture fails without it, snapshot diff purely additive).

What 5.5.6 actually changed

My "manualChunks hoists the import" framing above was too strong. The conversion is done by the plugin at transform time and doesn't depend on the adapter version. What changed in 5.5.6 is that the resulting import now survives into the output — 5.5.5 produced zero occurrences, 5.5.6 produces two. The bisect table stands; the attribution in it doesn't. 5.5.6 is where a latent bad transform becomes a shipped, unloadable bundle.

The version-3 line is not affected

main carries adapter-node 5.5.7 on rollup + @rollup/plugin-commonjs — that is the affected line, and the one this issue is about. The default branch version-3 carries adapter-node 6.0.0-next.7 on rolldown, and I could not reproduce there: built with @sveltejs/kit@3.0.0-next.14 / @sveltejs/adapter-node@6.0.0-next.7, using a synthetic CommonJS dependency with the same catch-clause require shape, rolldown emits

return __require("definitely-not-installed/package.json");

— a lazy runtime require, not a static import — and the server boots and serves normally.

So the bug is specific to the rollup pipeline on main/5.5.x, and won't follow the adapter into v6.

Separately: the class of bug is still reachable on version-3

While checking the above I found that an ESM dependency statically importing an unmet optional peer produces the same fatal-but-silent outcome there:

// build/instrumentation.server.js
import "not-installed-esm-package";

Build succeeds, server dies at boot with ERR_MODULE_NOT_FOUND. Rolldown warns Module not found, treating it as an external dependency, but it doesn't stop a bundle that cannot start from being written.

#16655 adds a guard for that against version-3: after bundle.write, resolve every bare import in the emitted chunks from the project root and fail the build naming anything that resolves nowhere. It's explicitly not a fix for this issue — it's what would have turned this into a build error instead of a production incident. Verified silent against a real app with ~130 bundled devDependencies. The same guard works on main/5.5.7, where it catches the @babel/preset-typescript case directly; happy to open that as a companion PR if it'd be useful on the released line.

Workaround, for anyone landing here

Two options, both verified on a full build:

• Pin @sveltejs/adapter-node to 5.5.4.
• Or, if Sentry is your trigger: raise @sentry/vite-plugin to >=5.4.0. It replaced @sentry/bundler-plugin-core with @sentry/bundler-plugins, which keeps Babel out of the bundled graph entirely. The range @sentry/sveltekit declares (^5.3.0) already allows it, so a lockfile refresh is enough. This keeps you on the current adapter, which is why we went with it.

[elliott-with-the-longest-name-on-github]

I'm confused. It is an error to statically import a module you don't have installed. We're not going to write code that attempts to resolve all of your imports for you. It seems like this is just a bug that needs to be fixed in @rollup/plugin-commonjs?

[Stadly]

You're right, and the version-3 framing was the weak part of this — rolldown already warns there, which I should have weighted properly before opening it against that branch. Closing #16655.

One note for the record, since it's the reason I went looking: on main/5.5.x rollup emits no warning at all for this, so the 5.5.6 case really was silent — the build succeeds, the image builds, and the container exits at boot with nothing else logged. That's a @rollup/plugin-commonjs problem rather than an adapter one though. rollup/plugins#2018 fixes it at the source (a require in a catch clause falls outside the ignoreTryCatch guard window, so it gets hoisted into a top-level import), and the rolldown pipeline already compiles the same input to a lazy __require(...) and boots fine.

Leaving this issue open against 5.5.x until that lands.

[Nic-Polumeyv]

@Stadly

When using AI to open issues or respond to maintainers, it's really important that you review the "word vomit" it produces before posting. I'm not speaking for anyone else here, just offering some advice as I'm extremely guilty of it too.

Two things stack up. We can tell when things are AI-written. Second, there's just too much information. Either one alone is survivable. There's absolutely nothing wrong and only good in helping AI write your words. But, naturally they put us (me, for the sake of not speaking for anyone else) in a frustrated headspace before we've even reached your point - and a frustrated reader skims. So we skim, and your actual issue gets lost in the sauce, for lack of a better phrase. Which spirals into issues like these unfortunately sitting cold.

Thank you!