Evidence (attached) suggests that the compartment mapper, when faced with multiple copies of the same package (name and version) will generate sequential numbers for their compartment names (-n1, -n2), but if some of those duplicates are not retained (no modules in that package were imported), the numbers will be non-sequential (-n2, -n4 or -n1, -n5). Evidence also suggests that which sequence number gets dropped is not deterministic.
These need to be reconstructed from the above evidence.
Expected behavior
The compartment maps should be deterministic on the sources.
Platform environment
Evidence above was gathered in a single Docker container with coherent versions of node and a single yarn.lock.
Additional context
It seems likely that this can at least be partially solved by omitting unretained compartments before generating sequence numbers for each compartment.
Describe the bug
Evidence (attached) suggests that the compartment mapper, when faced with multiple copies of the same package (name and version) will generate sequential numbers for their compartment names (
-n1,-n2), but if some of those duplicates are not retained (no modules in that package were imported), the numbers will be non-sequential (-n2,-n4or-n1,-n5). Evidence also suggests that which sequence number gets dropped is not deterministic.left.json right.json
Steps to reproduce
These need to be reconstructed from the above evidence.
Expected behavior
The compartment maps should be deterministic on the sources.
Platform environment
Evidence above was gathered in a single Docker container with coherent versions of
nodeand a singleyarn.lock.Additional context
It seems likely that this can at least be partially solved by omitting unretained compartments before generating sequence numbers for each compartment.
Screenshots