Bundle only one version of each package for each (name) or (name, version)

[kriskowal]

What is the Problem Being Solved?

A common problem for Agoric contract bundles is that package managers settle disputes by creating duplicate physical copies of packages, often for different versions of the same name, sometimes multiple copies for the same version. This causes bundle bloat. The bundler respects each physical copy, since the name is not a reliable reference to code in the face of npm: vs git: references or the application of patches with patch-package. The current failure mode leads to a great deal of coaxing the package manager to produce a single physical copy of each package.

In an alternate world, we could bundle the package with the “shortest dependency path” to each unique (name) or (name, version). (Aside for future work: We could even support a "nestedDependencies" package descriptor that creates eval twins from a single physical copy in the scope of a dependent package.)

Description of the Design

This would create a new behavior for the Compartment Mapper’s “Map Node Modules” feature based on the existing logic for “shortest dependency path from the entry package” (LavaMoat’s ’a’a), gathering all dependencies and accepting only one package per name at the shortest dependency path.

Security Considerations

This would have effects on the topology of a contract that would be reviewable under audit, but possibly distinct from the author’s intentions. The author of the contract would express their intentions in specific properties in package.jsons of their contract’s dependencies that would be honored differently by Endo than Node.js.

Scaling Considerations

Might help.

Test Plan

Requires the construction of fixture applications that would cause different behaviors with the current and proposed modes.

Compatibility Considerations

This feature must be enabled by a flag at the API layer. This might be papered over by the bundler. The bundler cache metadata will need to close over the flag.

Upgrade Considerations

Future bundles from the same application may differ from priors. The unit of continuity is the contract bundle, so reusing a bundle over upgrade will not change behavior. In some cases, regenerating bundles will produce identical behavior.