> 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
