ModuleImport

Bruno Jouhier bjouhier at gmail.com
Sat Jun 28 08:15:24 PDT 2014


Why make things so complex and introduce so many syntax variations? The
following should be sufficient:

import "underscore" as _; // var _ = require('underscore');

And there should be an API (not a language construct) to import a module
dynamically (and asynchronously). Something like:

promise = importModule(path);

Why introduce an export syntax? Why not just use this (or exports)?

this.foo = ... // or exports.foo = ...
this = .... // or exports = ..., similar to module.exports = ...
// importer obtains value of this / exports at end of module file,
// as if `return this` was added at the end of the file.

This would give the same power / flexibility as CommonJS and a simple
compatibility path. This would eliminate the "default" exports problem
because it would allow a module to export a function. It is also easy to
explain.

There is an operational requirement to have a special syntax for import
because this is what allows loaders to build a dependency graph and
optimize dependency loading. But there is no "operational" requirement to
have a special syntax for export. Static checking on exported members feels
odd.

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140628/286bec86/attachment.html>


More information about the es-discuss mailing list