Keep a namespaced package's dev modules out of its namespace
Why
The namespace map aliased every module of a package, its dev modules too. A package that opened a dependency's namespace got the dependency's dev modules in scope, which shadowed its own modules of the same name (#9089, #6679). The namespace map also depended on the dev modules, so a dev test that used the namespace entry was a dependency cycle.
The namespace map now holds only the regular modules. The dev modules get a second map, Ns-dev, which only the package's own dev modules open. bsc takes the alias targets from the map's file name, so it is dev/Ns.mlmap, compiled with -o Ns-dev. The new bsc flag -bs-open-alias-map opens it without recording its interface CRC, as -bs-ns does for the namespace; otherwise adding a dev module would break every dev module compiled against the previous dev map. The module graph and the editor analysis follow the same rule.
removedDiagnostic open of a dependency's namespace
// provider/test/Config.res (dev): let other = 2// consumer/test/Config.res (dev): let get = () => 3// consumer/test/Check.res (dev):open Providerlet value = Config.get()
diagnostic
The value get can't be found in ConfigremovedDiagnostic dev test using the namespace entry
diagnostic
Can't continue... Found a circular dependency in your code:@Provider (provider namespace map) → Provider.Local (provider/test/Local.res) → Entry (provider/src/Entry.res) → @Provider (provider namespace map)
modifiedRepresentation namespace maps of provider
text
Fixes #9089
Review
- Why a compiler flag and not a graph node for the dev map? The dev map only holds aliases, whose targets are recorded themselves, so its CRC does not need recording, the same reasoning as for -bs-ns. A graph node would recompile every dev module whenever one is added.