StencilJS production build omits lazy-loaded chunks referenced in chunk manifest

The short answer: your chunks are missing because the Stencil compiler only emits what it can trace statically. Any lazy-loading path built from a variable — import("./components/" + name) — is invisible to the build, while the manifest still records the component as lazy-loadable, so the runtime hydration script requests files that were never written to disk. The fix is to give the compiler a static enumeration of every component, and to keep one coherent output target configuration so the manifest and the emitted files agree.

1. Enumerate components so static analysis emits every chunk

Replace variable-based dynamic imports with a static registry the compiler can follow. The reliable pattern is an explicit map of literal import expressions:

const loaders = {
  'my-button': () => import('./components/my-button/my-button.js'),
  'my-card':   () => import('./components/my-card/my-card.js'),
  // one literal entry per lazy component
};

export function loadComponent(tag) {
  const loader = loaders[tag];
  return loader ? loader() : Promise.reject(new Error(`Unknown component: ${tag}`));
}

Each string literal is resolvable at build time, so every referenced module is split into a chunk and emitted. If you generate this map, generate it as source code with literal paths — not as runtime string concatenation. Note that in a standard Stencil project the component loader is generated for you from @Component metadata; this problem typically appears when you add a custom lazy-loading layer on top. If that describes your setup, prefer Stencil's own lazy loading and drop the custom indirection where possible.

2. Coordinate basePath and buildDir across output targets

The manifest mismatch comes from two targets writing different naming conventions into overlapping locations. Keep them separated and aligned:

• Give each output target its own buildDir (for example www/build for the www target and dist/custom-elements for dist-custom-elements). Never point two targets at the same directory.
• Set basePath to the exact public URL prefix where the assets will be served — the URL path, not a filesystem path. If the app is deployed under /app/, the manifest and chunk requests must resolve under that prefix.
• Clean the output directory before each production build so a stale manifest from a previous target run cannot survive alongside new chunks.

After building, verify consistency directly: open stencil-chunk-manifest.json and confirm every chunk it lists exists as a physical file in the same output tree, then load the page and check the network tab — the requested chunk URLs should match your configured basePath exactly. A 404 on a hashed filename almost always means a stale manifest or a basePath mismatch, not a missing build step.

3. Version pinning and the Vite-era pipeline

On current Stencil versions the bundling pipeline differs from the legacy Rollup-based one, and third-party Rollup plugins that inspect or rewrite chunk output can produce manifests the runtime loader cannot consume. The conservative steps:

• Pin @stencil/core to an exact version in package.json (no caret) and commit the lockfile so CI and local builds are identical.
• Audit stencil.config.ts for custom Rollup plugins that touch output filenames or manifests; remove or replace any that were written for pre-Vite Stencil. Test this by running a clean production build and diffing the manifest against the emitted files.
• When upgrading major versions, follow the official migration guide for your target version and re-run the full lazy-loading path in a staging deploy, not just the dev server — the dev server compiles on demand and will hide exactly this class of bug.

One caveat worth flagging: the exact chunk-naming and manifest behavior varies across Stencil 4.x minor releases, so treat the verification steps above (manifest-to-file diff plus a network-tab check) as the source of truth for your pinned version rather than any general claim about naming conventions. If chunks still 404 after the registry and target cleanup, the one diagnostic detail that would change the recommendation is whether the missing chunk names appear in the manifest with hashes that match files on disk — that distinguishes a static-analysis gap from a deployment path mismatch.