ModuleImport

Brian Di Palma offler at gmail.com
Fri Jun 27 15:51:29 PDT 2014


Andreas, I hope you're not just getting my hopes up with the
possibility of checking ModuleImports too.
That would be great. I was disappointed that they weren't originally.

Making

    module fs from 'fs';

    fs.readFile(...);

and

    import {readFile} from 'fs';

equivalent in terms of static checks is the right approach.

If the cost of these improvements is not having default exports it
seems acceptable.
In essence we would have to write

    import {jquery} from 'jquery';

instead of

    import jquery from 'jquery';

The "flexibility" of not having to know the export identifier is
worthless to me.
I can't see how I could make use of a module without reading some
documentation on it, which will show me the identifiers.

> Static checking and lazy binding should be "value added features", not something I have to think about every time I import a module.

I don't understand how you can make use of what you require without
reading some sort of documentation or code.
This will be an even smaller "cost" once tooling supports ES6 modules
as it will allow autocompletion of imports statements.


More information about the es-discuss mailing list