Discuss
  • External and internal modules

External and internal modules

# Dmitry Soshnikov (12 years ago)

Couple of questions on current modules system (as I see, they are not part of recent ES6 draft, the only thing which exists is this wiki article: harmony%3Amodules).

  1. By prediction and observing of current situation with "require" modules system, 90% of modules will be external modules, that is live in separate files, which contain module bodies directly.

  2. As I understand, this module "foo" { ... } way of defining is either for inner modules (inside a parent external modules), or inside an external file which is not a module, but a script (and therefore, cannot be loaded as module).

The first case isn't that useful -- I defined an inner module inside a parent external module, and then what? -- import it exactly in the same file? What is that mean? Naming collisions happen not that often inside a module (this is why it's a module), that sub-devide it on sub-modules.

Or can I probably export this inner submodule from the parent? How this double import will look like, if it's even possible? First import the inner module form the parent, then bindings from the inner?

If the parent file is not actually a module, but a script -- how this script is loaded? On the web using <script>? On Node.js? -- using ..."require"? Two module systems?

  1. For external modules, will it be possible to omit filename extension? import foo from "foo.js" -- sounds obsolete, unless we'll be able to import modules written on different languages.

  2. What is export from module?

import {foo} from "foo.js";
export {foo} from "foo.js"

First makes sense to me (well, syntax is debatable, but anyways), the second I don't understand. Can I, as a caller, re-export (i.e. make public) something from not my module, and that was specially not exported?

# Sam Tobin-Hochstadt (12 years ago)

On Mon, Sep 9, 2013 at 3:33 AM, Dmitry Soshnikov <dmitry.soshnikov at gmail.com> wrote:

2. As I understand, this module "foo" { ... } way of defining is either for inner modules (inside a parent external modules), or inside an external file which is not a module, but a script (and therefore, cannot be loaded as module).

The first case isn't that useful -- I defined an inner module inside a parent external module, and then what? -- import it exactly in the same file? What is that mean? Naming collisions happen not that often inside a module (this is why it's a module), that sub-devide it on sub-modules.

Or can I probably export this inner submodule from the parent? How this double import will look like, if it's even possible? First import the inner module form the parent, then bindings from the inner?

There are no nested modules.

If the parent file is not actually a module, but a script -- how this script is loaded? On the web using <script>? On Node.js? -- using ..."require"? Two module systems?

Bundled collections of modules are loaded primarily by loading them or referencing them using a module loader, and then importing from the individual modules they define.

3. For external modules, will it be possible to omit filename extension? import foo from "foo.js" -- sounds obsolete, unless we'll be able to import modules written on different languages.

In the browser (this is not intended to be part of the language semantics), the default rule for going from a module name like "foo" to a URL like "example.com/foo.js" will add ".js".

4. What is export from module?

import {foo} from "foo.js";
export {foo} from "foo.js"

First makes sense to me (well, syntax is debatable, but anyways), the second I don't understand. Can I, as a caller, re-export (i.e. make public) something from not my module, and that was specially not exported?

No, you can't. The latter means the same as:

import { foo } from "foo";
export { foo };

except without adding foo to the local scope. It doesn't expose anything unexported.

# Dmitry Soshnikov (12 years ago)

On Mon, Sep 9, 2013 at 6:26 AM, Sam Tobin-Hochstadt <samth at cs.indiana.edu>wrote:

There are no nested modules.

Thanks, let me understand further:

So, technically, if I have an external file "foo.js" like this:

export function foo() {};
module "bar" {}

then it's illegal (I have a nested module "bar" inside module "foo" represented by "foo.js")?

What if "foo.js" doesn't contain "export" statements?

function foo() {};
module "bar" {}

Is it a bundled module collection now (with the only module "bar" inside)? And this file can be loaded only via module loader as you mention below, but not using "import" or "module" statement?

Bundled collections of modules are loaded primarily by loading them or referencing them using a module loader, and then importing from the individual modules they define.

To double-check:

File "foo.js":

export default function foo() {}

can be loaded as:

import foo from "foo";

or:

module foo from "foo";

But the file "bar.js":

module "bar" {
  export default function bar() {}
}

Cannot be loaded as:

import bar from "bar";

or:

module bar from "bar";

?

In other words, everything we want to be loaded via "import" or "module" statements, should be file-modules, not inner modules with "module" directive, correct?

In the browser (this is not intended to be part of the language semantics), the default rule for going from a module name like "foo" to a URL like "example.com/foo.js" will add ".js".

OK.

No, you can't. The latter means the same as:

import { foo } from "foo";
export { foo };

except without adding foo to the local scope. It doesn't expose anything unexported.

I see, so it's just further propagation passing export of not my module through from my module, as it would be my export; thanks.