Discuss
  • State of discussion - module / Import syntax

State of discussion - module / Import syntax

# Aron Homberg (13 years ago)

I found that the recent draft / harmony PDF doesn't include a specification of the import syntax and just wanna ask if the following wiki pages in (harmony namespace) reflect the current state of discussion and if there are big changes to expect in the future regarding this:

http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples&s=import

If it's relatively "stable" I would start prototyping the import syntax in my Traceur clone.

Thanks and , Aron

# Jussi Kalliokoski (13 years ago)

I find this interesting as well, because I've been thinking of creating Yet Another(TM) module loader, which would be a standalone polyfill for Harmony modules.

While we're at it, a few questions I've been wondering:

  • Is it possible to have modules that don't export anything? I suppose this would allow existing scripts like jQuery to work out of the box, if they tie their exports to the window object, then just do import "jquery.js" or import * from "jquery.js" if necessary.
  • If there's a cross-compilation hook on the loader, does the dependency resolving happen before or after the compilation? Former is more efficient, but places constraints on the compile-to-JS languages.
  • Is there a way to do async cross-compilation with the hooks? e.g. offload parsing and everything to a worker to keep the main thread responsive?
  • Is it possible to import things to local scope? For example, is this a syntax error, and if not, what happens: function x () { import y from x }
# David Herman (13 years ago)

Need just a bit more time to work through some module details work. I get back from Strange Loop mid-week and hope to really start tackling module work in earnest next week.

# Shijun He (13 years ago)

On Tue, Sep 25, 2012 at 1:02 AM, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> wrote:

I find this interesting as well, because I've been thinking of creating Yet Another(TM) module loader, which would be a standalone polyfill for Harmony modules.

I just wrote one: hax/my.js/blob/master/src/loader.js

  • If there's a cross-compilation hook on the loader, does the dependency resolving happen before or after the compilation? Former is more efficient, but places constraints on the compile-to-JS languages.

I also have the same question. Currently Loader API does not provide feature to define module dependencies, so only latter is possible as current draft. In my.js loader implementation, I add extra "references" property which is accessible in hooks to make former works.

  • Is there a way to do async cross-compilation with the hooks? e.g. offload parsing and everything to a worker to keep the main thread responsive?

+1. Currently only fetch hook is async, I think translate hook could also be async so that we can utilize Worker.

On the other hand, fetch hook could also be sync. In fact I suggest follow API:

options.fetch( relURL, baseURL, resolved )

fetch hook returns String (fulfill) or Module instance (skip translate hook) or throws (reject) or returns a Promise object as async form.

options.translate( data:ModuleData )

ModuleData structure: { data: String // code source type: String // mimetype such as text/coffeescript uri: String // code uri references: [String] // uri references for dependencies relativeURL: String // relURL baseURL: String resolved: Any // Note: I dont think relativeURL/baseURL/resolved are useful for translate hook but just keep them as current draft }

translate hook returns ModuleData or String (translated source) or Module instance (skip parent loader translate hooks) or throws (compilation error) or returns a Promise object as async form.

  • Is it possible to import things to local scope? For example, is this a syntax error, and if not, what happens: function x () { import y from x }

I think it should be syntax error.