Member Junction
    Preparing search index...
    • Resolve a lazy package's subpath exports, refusing to answer "none" when the package declares typed subpaths it simply hasn't built yet.

      Call this only for a package that contributes lazy classes. resolveSubpathExportsDetailed() reads the .d.ts each exports entry's types field names and records the subpath only if classes are reachable from it, so an empty result is perfectly ordinary in two innocent cases: a subpath whose .d.ts declares no classes, and a package with no code subpaths at all. Neither is a problem when there are no classes to group.

      With classes present it is a different matter. An empty map sends every one of them down the whole-package branch of groupClassesIntoChunks(), replacing the package's per-subpath lazy chunks with a SINGLE eager chunk. The emitted config is still valid TypeScript, still compiles, still passes review — it has just had its code splitting deleted, and nothing downstream can tell the difference.

      So refuse. A missing build is recoverable in one command; a silently de-optimised bundle shipped to production is not.

      Parameters

      • packageName: string
      • packageDir: string

      Returns Map<string, SubpathExportInfo>

      when packageDir declares typed subpath exports but none of them resolve.