fix: resolve named CommonJS imports in dev-server bundling ("No matching export")

[theoryeffects]

Fixes #83.

Problem

On the Angular 22 line, ng serve fails while bundling external npm packages when a shared library imports a named export from a CommonJS package — e.g. import dayjs, { isDayjs } from 'dayjs':

X [ERROR] No matching export in "node_modules/dayjs/dayjs.min.js" for import "isDayjs"

The production build (ng build) of the same workspace succeeds. It also reproduces with, for example, quill importing { Op, AttributeMap } from quill-delta.

Root cause

In src/tools/esbuild/node-modules-bundler.ts, advancedOptimizations = !dev, so it is false during ng serve. The angular-linker plugin's onLoad then early-returns for any file that does not need Angular linking:

if (!needsLinking && !advancedOptimizations) {
  return null;
}

That early return skips jsTransformer.transformData, which is what performs the CommonJS→ESM interop that synthesizes named exports. So in dev, CommonJS vendor files reach esbuild untransformed and esbuild cannot resolve { named } imports from them. In production advancedOptimizations is true, every file is transformed, and the named exports resolve — which is why ng build works and ng serve does not.

In short: CommonJS-interop correctness is currently coupled to the advancedOptimizations optimization level.

Fix

Keep the dev fast-path for genuine ESM vendor files, but do not skip CommonJS files — they still need the interop transform. This preserves fast dev builds (only CommonJS modules pay the transform cost) instead of forcing advancedOptimizations on in dev:

const maybeCommonjs = /\bmodule\.exports\b|\bexports\.[A-Za-z_$]/.test(contents);

if (!needsLinking && !advancedOptimizations && !maybeCommonjs) {
  return null;
}

The CommonJS check is a lightweight heuristic; happy to switch it for a more robust detector if you would prefer.

Reproduction

1. A Native Federation v22 host that shares a library doing import def, { named } from '<cjs-pkg>' where <cjs-pkg>'s main entry is CommonJS (e.g. dayjs).
2. ng build → succeeds.
3. ng serve → X [ERROR] No matching export in "node_modules/<cjs-pkg>/..." for import "named".

Verification

• pnpm build and pnpm lint pass; the changed file introduces no new lint findings.
• This change (applied as a patch-package patch of the same logic) has been running in a real Angular 22 host: ng serve bundles the previously failing CommonJS dependencies without error, and the production build is unchanged.

Note

@chialab/esbuild-plugin-commonjs is already registered in the same plugin chain but does not resolve these named imports in dev. It may be worth confirming whether it is expected to cover this case; regardless, decoupling the interop from advancedOptimizations fixes the dev/prod discrepancy.