This updates the input map decomposition to handle a new feature which is that it's possible for the same package name in an import map to flatten multiple versions into the flattened scope. We maintain this as special "flattened resolution" data which is like normal resolution data but also keyed by subpath, which is extracted during decomposition and then repopulated into the specific scopes as the main install trace runs.
One dependency may have had import 'dep' to dep version 1, while another dependency had import 'dep/feature' to dep version 2. Flattening is able to combine these scopes when the import map is output since there isn't any duplication at the specifier level, but we then end up with the same package name having different versions for different subpaths.
This resolution information is now fully reconstructed in the lock data structure and maintained - whereas before one version would override the other.
Note that in "imports" one version will still override the other when this happens, since at the dependency level there is still the expectation that you only have one version of a dependency, or if you have multi versions of a dependency that you at least use aliasing (interestingly, @fusionstrings this exactly comes up at the same time as you brought up this point!).
This updates the input map decomposition to handle a new feature which is that it's possible for the same package name in an import map to flatten multiple versions into the flattened scope. We maintain this as special "flattened resolution" data which is like normal resolution data but also keyed by subpath, which is extracted during decomposition and then repopulated into the specific scopes as the main install trace runs.
For example. consider the map:
One dependency may have had
import 'dep'to dep version 1, while another dependency hadimport 'dep/feature'to dep version 2. Flattening is able to combine these scopes when the import map is output since there isn't any duplication at the specifier level, but we then end up with the same package name having different versions for different subpaths.This resolution information is now fully reconstructed in the lock data structure and maintained - whereas before one version would override the other.
Note that in
"imports"one version will still override the other when this happens, since at the dependency level there is still the expectation that you only have one version of a dependency, or if you have multi versions of a dependency that you at least use aliasing (interestingly, @fusionstrings this exactly comes up at the same time as you brought up this point!).Resolves https://github.com/jspm/generator/issues/165.