Named exports that are functions can be elevated incorrectly.

[rwjblue]

The following input:

var foo = "bar";

if (false) {
  someFunction = function foo() {  };
}

export {
 foo 
}

Results in:

define(['exports'], function (exports) {

  'use strict';

  exports.foo = foo;

  var foo = "bar";

  if (false) {
    var someFunction = function foo() {  };
  }

});

---

It seems that since a function named foo existed (even though it was not available as foo since it was assigned to someFunction variable) the transpiler assumed that it could hoist the named export to the beginning of the file. In this case, it results in exports.foo being undefined when later required by other modules.

[rwjblue]

For a less contrived example, see the following code in Ember:

• defineProperty variable here
• defineProperty function polyfill here

The resulting named export of defineProperty is undefined (since there was no function available but the exports.defineProperty = defineProperty; was hoisted to the beginning of the AMD module).

[rwjblue]

Another example:

var foo = function foo() { }

export {
 foo 
}

define(['exports'], function (exports) {

    'use strict';

    exports.foo = foo;

    var foo = function foo() { }

});

It is obvious that var foo = function foo() { } doesn't make sense, but it would be nice if the transpilation step didn't cause this failure.

[Rich-Harris]

I have this fixed locally - am on a plane with crappy WiFi, will push later

On Sun, 25 Jan 2015 13:06 Robert Jackson notifications@github.com wrote:

Another example:

var foo = function foo() { }
export {
foo
}

define(['exports'], function (exports) {

'use strict';

exports.foo = foo;

var foo = function foo() { }

});

It is obvious that var foo = function foo() { } doesn't make sense, but
it would be nice if the transpilation step didn't cause this failure.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.