ModuleImport

Bruno Jouhier bjouhier at gmail.com
Sun Jun 29 11:08:33 PDT 2014


> CommonJS falls a bit short on the import side because static analysis of
>>> require calls is brittle. A special language syntax would enable a robust
>>> static analysis of dependencies.
>>>
>>
>> If you don't have static exports, then how are you going to know if what
>> you import is valid?  You can't, without executing the program.
>>
>
The main purpose of modules is not to provide static type checking but to
prevent global scope pollution and allow loaders to load source code
reliably and efficiently. What I meant by "static analysis" was the ability
for a loader to bundle all the dependencies so that they can be transported
efficiently. With require this analysis is brittle because require is not a
reserved keyword and its argument can be any expression.

It is important to focus the design on loader issues and keep things
orthogonal.

Why reinvent a special destructuring syntax when this is already addressed
by existing language constructs? It can be handled by allowing any LHS
after the as keyword: import "module_path" as lhs_expression;

Why bother about about static type checking? If you want static typing, use
Typescript, your modules will be exporting typed APIs; if you don't care
use JavaScript.

Sorry for the previous empty post. I hit the wrong key.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140629/0fdefb5f/attachment-0001.html>


More information about the es-discuss mailing list