Ola

Small addition on why the production build was fine, since that difference misleads people into thinking their dev config is at fault.

Development and production usually go through genuinely different paths: different chunking, different module wrapping, and in a lot of tools the dev server does not do the same bundling at all. So "works in the build, breaks in dev" is not evidence about your configuration - it is evidence that the broken code path only exists in one of the two modes.

The practical consequence is the uncomfortable one: your production build passing is not a check on this. A regression that only appears in dev will not be caught by any pipeline that only builds, which is most of them. If the dev server is how the team works all day, it is worth having something that actually starts it and loads a page, even if that is one smoke test.

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.