FynMesh API
    Preparing search index...

    Interface CombineConfig

    How to group chunks into combined files.

    interface CombineConfig {
        dropIndividual?: boolean;
        dryRun?: boolean;
        exclude?: string[];
        groups?: Record<string, string[]>;
        log?: (message: string) => void;
        maxBundleSize?: number;
        maxModuleSize?: number;
        measure?: "raw" | "brotli";
        minGroupSize?: number;
    }
    Index
    dropIndividual?: boolean

    Delete each member's individual file, leaving the combined file the only copy. Saves disk, not bandwidth — and it removes the fallback that makes a stale map cost one request instead of a failure. It also makes this step non-repeatable, since there is nothing left to re-combine.

    dryRun?: boolean

    report what would change without writing anything

    exclude?: string[]

    fileNames or stems that must stay in their own file

    groups?: Record<string, string[]>

    Explicit groups: group name -> chunk fileNames or chunk stems (hello for hello-DqD-ezWy.js). These bypass the size rules entirely, which is how a known startup set is kept together and a cold chunk is kept out of a hot group.

    log?: (message: string) => void

    where progress goes; defaults to console.log

    maxBundleSize?: number

    Stop adding to a group once the file it would produce reaches this many bytes (default 32768).

    The file, not the sum of its members: under measure: "brotli" those are far apart, because brotli shares one window across the concatenation and a group of near-identical federated chunks compresses to a fraction of what they cost separately. The sum is kept as a cheap upper bound and the concatenation is measured only where it decides the outcome.

    maxModuleSize?: number

    only chunks at or below this many bytes are candidates (default 2048)

    measure?: "raw" | "brotli"

    Which byte count the size rules act on (default "raw").

    "brotli" measures each chunk compressed at quality 11, matching what a server with precompressed siblings actually puts on the wire. That is the number the decision is really about — combining exists to stop paying a round trip for a payload smaller than the overhead of asking for it — and raw size is a poor stand-in for it: across one real app's chunks the ratio ran from 15% to 74%, so a raw threshold both admits chunks that are expensive to transfer and excludes chunks that are nearly free.

    Costs one q11 compression per candidate at build time, plus one per chunk in the top-up region at the end of a group (see maxBundleSize). Reported sizes stay raw either way; only the thresholds change meaning.

    Anything other than these two values is refused rather than quietly treated as raw: a build that looks configured and is not is worse than one that stops.

    minGroupSize?: number

    a group needs at least this many chunks to be worth emitting (default 2)