Duplicate keys in object literals transpile to ES5-incompatible JS

[jussi-kalliokoski]

The following ES6 code:

var x = {x: 1, x: 2};

generates the following code:

"use strict";

var x = { x: 1, x: 2 };

which will result in an error for ES5-compliant engines. I'm not sure what should be done here instead as duplicate keys are back to being valid in strict mode in ES6, but maybe something like this:

"use strict";

var x = { x: 1 };
x.x = 2;

This bug also occurs with JSX:

var x = <x x={1} x={2} />;

becomes

"use strict";

var x = React.createElement("x", { x: 1, x: 2 });

[sebmck]

This will have to be done with another transform. Seems easy enough.

[jussi-kalliokoski]

Yeah, something like this seems to produce working code (horribly inefficiently though) if placed after the JSX transforms and before other ObjectExpression related transforms:

export default function ({Plugin, types: t}) {
  function getName (key) {
    if ( t.isIdentifier(key) ) { return key.name; }
    return key.value.toString();
  }

  return new Plugin('duplicate-property-keys-to-es5', {
    visitor: {
      ObjectExpression (node) {
        const plainProps = node
          .properties
          .filter(prop => !t.isSpreadProperty(prop))
          .filter(prop => !prop.computed);

        plainProps
          .filter((prop, index) =>
            plainProps
              .slice(0, index)
              .some(previousProp =>
                getName(prop.key) === getName(previousProp.key)
              )
          )
          .forEach(prop => {
            prop.computed = true;
            prop.key = t.literal(getName(prop.key));
          });
      }
    }
  });
}

[petetnt]

Maybe this should be an option with a sensible default (IMHO default being error, because one could argue that 99% of the times duplicate key is an (user) error)? Others being something like warn (current behavior + warning) and overwrite (which is non-strict mode ES5 default)? Duplicated property values are allowed in ES6, though I think the restriction was removed because of duplication being possible due to computed property values on runtime being possible, right? MDN says that:

In ECMAScript 5 strict mode code, duplicate property names were considered a SyntaxError. With the introduction of computed property names making duplication possible at runtime, ECMAScript 6 has removed this restriction.

[jussi-kalliokoski]

I think that sounds more like the job of a linter - there's plenty of other silly things you can do with the language that babel doesn't warn nor throw for. IMO what babel should do here is just produce valid JS.

[petetnt]

Yeah, I was thinking about that. I have always set my linters to throw on duplicated keys (and other duped ones like variable names) and I do agree that babel should produce is valid JS and that there are tons of silly things that are better left for the linter or coder to handle.

But then again the expected outcome is hard to say in a transpiling cases like with babel: duplicate keys is most likely something that is not expected (especially with non-runtime, precomputed values). But you are right, it should be left for linters to handle.

[Macil]

Perhaps this could be simple to implement if duplicate keys were treated the same way as computed keys. var x = {o: 5, o: 6}; could be treated like var x = {o: 5, ["o"]: 6}; and transpiled to the same thing using the same logic.

[babel-bot]

Comment originally made by @agentme on 2016-01-15T22:39:26.000Z

I see now that jussi-kalliokoski had already posted code to do my idea. [[ https://github.com/AgentME/babel-plugin-transform-es2015-duplicate-key-fix | I've just tweaked the code a little ]] and published it on NPM as "babel-plugin-transform-es2015-duplicate-key-fix", and then I published a fork of the es2015 preset that includes it as "babel-preset-es2015-dupkeyfix".

---

Comment originally made by @amasad on 2016-02-03T01:21:50.000Z

Just exclude the strict plugin which or use strict: false option if you want to use babel in non strict mode (which will allow duplicate keys)

---

Comment originally made by @hzoo on 2016-03-02T02:04:59.000Z

Merged #3280