transform-es2015-modules-commonjs destructuring error

[jonhartnett]

When destructuring into an exported variable, transform-es2015-modules-commonjs fails to generate code to keep the local variable and the exports value in sync.

Input Code

export let x = 0;
export function f1(){
    x = 1;
}
export function f2(){
    [x] = [2];
}
export function f3(){
    ({x} = {x: 3});
}

Babel Configuration (.babelrc, package.json, cli command)

{
  "plugins": ["transform-es2015-modules-commonjs"]
}

Expected Generated Code

"use strict";

Object.defineProperty(exports, "__esModule", {
    value: true
});
exports.f1 = f1;
exports.f2 = f2;
exports.f3 = f3;
let x = exports.x = 0;
function f1() {
    exports.x = x = 1;
}
function f2() {
    [x] = [2];
    exports.x = x; //this is one possible solution
}
function f3() {
    ({ x } = { x: 3 });
    exports.x = x;
}

Current Generated Code

"use strict";

Object.defineProperty(exports, "__esModule", {
    value: true
});
exports.f1 = f1;
exports.f2 = f2;
exports.f3 = f3;
let x = exports.x = 0;
function f1() {
    exports.x = x = 1;
}
function f2() {
    [x] = [2];
}
function f3() {
    ({ x } = { x: 3 });
}

Possible Solution

Add a line to keep the local variable and the export value in sync when destructuring into export variables.

software	version(s)
Babel	6.24.1
babel-plugin-transform-es2015-modules-commonjs	6.24.1

[babel-bot]

Hey @jonhartnett! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[joshwnj]

@jonhartnett this is interesting. Do you know whether this is even expected behaviour of javascript?

I'm not 100% up to scratch with how the bindings work, but it may be because in this case x is value rather than a reference.

For example, if we're dealing with an object reference instead of a value:

let y = exports.y = { val: 1 };

function f2 () {
  [y.val] = [2]
}

calling f2() does update both y and exports.y.

If anyone can weigh in on whether this is expected behaviour according to the module spec, that would be very helpful :)

[jonhartnett]

As far as I know module bindings should be "live", any updates should be visible from outside the module. Furthermore, the line in f3 should behave as nothing more than syntactic sugar for
x = ({x: 3}).x
You can see from the differing output if you make that change, that this is indeed a bug and not "unexpected" expected behavior.

[joshwnj]

@jonhartnett ahh you're right - I was thinking from the point of view of the commonjs module but I see what you mean now.

I think I've got something working for this, just pushing a PR for review now.

[joshwnj]

@jonhartnett when you have a moment please try #5811 and see if that works for you.

[jonhartnett]

@joshwnj That works perfectly