Dev server dies with a single mangled identifier and no stack trace after a patch upgrade — how do I even start on this?

Start by reading the identifier as what it is rather than as a message, because it is not one.

An init_<something>_esm symbol is a module initialiser the bundler generated. When a bundle is split into chunks, each module gets a small function whose job is to run that module's top-level code exactly once, and other chunks call it before touching anything the module exports. The name is assembled from the module's path, which is why the library's name is sitting in the middle of it.

So the identifier tells you which module failed to be initialised. It does not tell you who broke it, and in this class of bug it is almost never the named library. The library is the victim: it is simply the one that happened to be reached first through a chunk boundary the bundler got wrong.

That also explains your two clues, and they are the strongest evidence you have:

• Turning off code splitting fixes it — because with one chunk there are no cross-chunk initialiser calls at all. The bug cannot express itself.
• The named library did not change — because the fault is in the thing that decides how modules are grouped and in what order they wake up.

Which points at exactly one place: the bundler underneath your build tool. Modern build tools are a thin layer over a separate bundler, and a patch release of the outer tool routinely pulls in a new version of the inner one. Your one-patch bump was not a one-package bump.

Check what actually moved. The lockfile diff for that upgrade will show the bundler's version changing alongside the tool's, and that is your real suspect.

Following on: once you know it is the inner bundler, you do not have to choose between the old build tool and a broken dev server. You can hold the build tool where it is and pin the transitive dependency back.

Every package manager has a mechanism for this, they just disagree on the name and on how far it reaches:

• npm and pnpm read an overrides block
• Yarn calls the same idea resolutions
• pnpm additionally has a resolutions field under its own key, which behaves slightly differently for nested ranges

All of them do the same job: force every copy of a package to a version you name, regardless of what asked for it. Add it, delete the lockfile entry or reinstall so it takes effect, and confirm with whatever why/list command your manager offers that only one version is present. That last check matters — the most common failure here is that the override applied to some of the tree and something else pulled a second copy in.

Two rules for using this, learned the hard way:

Write the reason next to it. An override with no comment is indistinguishable from a mistake six months later, and the person who finds it will either be too scared to remove it or will remove it on the wrong day.

Make it expire. A pin is a bet that upstream will fix this, and they usually do — this exact class of bug tends to be resolved in the bundler and then picked up by the next minor of the build tool. Put a reminder against it, because the failure mode of pinning is not breakage, it is that you are still on a year-old bundler and nobody remembers why.