Renaming of variables?

[dbashford]

import bar from 'foo'
bar.what();

Turns into this

(function () {
    'use strict';
    var foo = require('foo');   
    foo.default.what();
}).call(global);

So bar is renamed to foo. If I have a foo or declare a foo I'll get a collision. Also debugging could become a pain with the name change, but source maps take care of that (just haven't got to that yet).

Guess the renaming was purposeful?

[dbashford]

Should say, if it was purposeful and the collision issue is an understood and calculated risk, figuring its not a common use case, that's cool. Not sure what the mitigation would be in other than to check variables in scope... or to be in scope... which may be a bridge entirely too far given the odd use case.

[Rich-Harris]

Yeah, I realised this the other day but hadn't got round to creating an issue. It is purposeful - if you're in non-strict mode, you get this result...

(function () {
    'use strict';

    var bar = require('foo')
    bar.what();
}).call(global);

...which is both more readable than __imports_0 or whatever, and guarantees no collisions (because a var bar or function bar () {} in the same module would be a syntax error). Something similar needs to happen for strict mode transformations - will mark this as a bug.

Bundling is a bit trickier, because you need a variable name based on the module ID rather than the import name (otherwise it might vary within the bundle), and you have to deconflict across all modules. Still do-able though

[Rich-Harris]

@dbashford This behaves a bit better in 0.4.7 - default imports like import bar from 'foo' will infer the variable name from the import declaration; batch imports (import * from 'fs') will do likewise. If you're using named imports, the module name will be based on the path (relative to the module), but if that collides with variable names it will keep prefixing it with _ until there's no collision.