>
>
> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <calvin.metc...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
