The section on Modular Package Structure in the Modules doc states:
When you use api.mainModule, the exports of the main module are exposed globally as Package[“my-modular-package”], along with any symbols exported by api.export, and thus become available to any code that imports the package. In other words, the main module gets to decide what value of Foo will be exported by api.export, as well as providing other properties that can be explicitly imported from the package:
// In an application that uses my-modular-package:
import {Foo as ExplicitFoo, bar} from "meteor/my-modular-package";
console.log(Foo); // Auto-imported because of api.export.
console.log(ExplicitFoo); // Explicitly imported, but identical to Foo.
console.log(bar); // Exported by server.js or client.js, but not auto-imported.
Note in particular the line:
console.log(Foo); // Auto-imported because of api.export.
Aliases in imports are usually used to resolve namespace clashes. i.e. If two modules contain a named export for “Foo”, we’ll need to alias one of them to something that doesn’t clash.
If the above comment is true, then is not the whole reason for using an alias in an import being subverted? It seems to me that Meteor should not be auto-importing the api.export in a case where an explicit import has renamed it.
Where is the problem here, in the documentation, the implementation, or my understanding?