Is it possible to have deterministic build output?

[scameron]

Hello,

Every time I run our build, if I look at the size of the output chunk files, it is different every single time. Usually the number of chunk files is the same, but the size on disk of the files is different. None of the source code or settings have changed in between builds. This is just running the same build multiple times.

Here are the total chunk sizes from 8 runs of our build, one after another, in bytes:

• 200011996
• 200027705
• 200011666
• 200020535
• 200016600
• 200020336
• 200050837

The difference between the biggest and smallest is 39171 bytes. Percentage-wise this is totally insignificant, like 0.02% of the total build size. So it's not a problem for the build itself.

The problem is that we are trying to implement build checks that detect when somebody has made a change that is causing the build output to increase. And with non-deterministic output, it makes it difficult to pin down a specific change to blame, so we can catch it before it gets merged. A commit that increases the size, might make it under the current threshold, and then that code could accidentally fail the check in somebody else's PR because they happen to be unlucky and hit a build that comes in on the high side.

We could implement our check based on module sizes, but that doesn't take into consideration the duplication that can happen during chunk splitting. We're hoping to have out check be done on the true final output size of the build.

Any ideas about why this non-deterministic output might be happening? I'm guessing it's during splitChunks, but I don't know for sure.

[alexander-akait]

Can you provide your configuration?

[scameron]

In the example I'm looking at, I don't see any export something from "./test.js", but it's possible I'm just not looking far enough up the graph. The NaN module itself exports only a single JS object. That module is imported by another module that exports a single function (returning an object). And then there is a dynamic import in a 3rd module that imports the whole 2nd module. Then there are many callers of that dynamic import.

Could you elaborate a bit about what you'd like me to try inside OccurrenceModeulIdsPlugin? It looks like your suggestion might have been truncated...

[alexander-akait]

Could you elaborate a bit about what you'd like me to try inside OccurrenceModeulIdsPlugin?

Just ignore zero chunk modules

[scameron]

I made a small modification to countOccursInEntry in OccurrenceModuleIdsPlugin that seems to work. The NaN values are gone and the build output is completely stable down to the byte now:

const countOccursInEntry = module => {
    let sum = 0;
    for (const [
         originModule,
         connections
    ] of moduleGraph.getIncomingConnectionsByOriginModule(module)) {
        if (!originModule) continue;
        if (!connections.some(c => c.isTargetActive(undefined))) continue;
        sum += (initialChunkChunkMap.get(originModule) || 0)
    }
    return sum;
};

The only change I made is to the line sum += (initialChunkChunkMap.get(originModule) || 0) where I use a 0 if originModule is not found.

[alexander-akait]

Yeah, I think it is valid solution, can you send a PR?

[scameron]

I created PR #16933 but it looks like I don't have rights to add reviewers. Can you add yourself in there?