ModuleImport

Jacob Gable jacob.gable at gmail.com
Thu Jun 19 08:18:27 PDT 2014


>
>
> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <calvin.metcalf at gmail.com>
> wrote:
>
>> One other option could be for import name from 'path'  to resolve to the
>> module body there is no default export, thanks to the static analysis
>> you'll always know when default is present.
>>
> That is a refactoring hazard. If the module changes to add/remove the
> default export the import will still succeed but the value is either a
> module instance object or anything:
>
> // a.js
> export default class C { ... }
>
> // importer.js
> import A from './a';
> new A();
>
> Now a.js changes.
>
> // a.js V2
> export class C { ... }
>
> // importer.js
> import A from './a';
> new A();  // TypeError: A is not a function
>
> With this idea you cannot look at the import statement to see if the
> imported binding is a module instance object or not.
>
>
>
For what it's worth, I have built a sort-of static analysis tool that would
give you visibility to these sort of refactoring changes.  We currently use
it on our code base of around 250 module files that are transpiled on
deployment.

- es6-import-validate, https://github.com/sproutsocial/es6-import-validate
- Also available as a grunt plugin,
https://github.com/sproutsocial/grunt-es6-import-validate

Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140619/efa5f620/attachment.html>


More information about the es-discuss mailing list