Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated function definition code is semantically incorrect. #10303

jonathanmarvens opened this issue Aug 7, 2019 · 4 comments


Copy link

commented Aug 7, 2019

Bug Report

Let’s say you have a variable function_ in which you want to create and store an arrow function with the .name of 'foo'. One might, at first, attempt to do the following:

const function_ = () => {}

Obviously, this doesn’t work since the created function’s .name will reflect the variable’s name. A way to go about accomplishing this is using a pattern like the following:

const function_ = ({
  foo: () => {}

Given how bindings are handled, that solves the problem, and the following should work as well:

const functionName = 'foo'
const function_ = ({
  [functionName]: () => {}

When compiled by Babel, code like the following is generated:

"use strict";

var function_ = {
  foo: function foo() {}
"use strict";

function _defineProperty(obj, key, value) {
  if (key in obj) {
    Object.defineProperty(obj, key, {
      configurable: true,
      enumerable: true,
      value: value,
      writable: true
  } else {
    obj[key] = value;
  return obj;

var functionName = 'foo';

var function_ = _defineProperty({}, functionName, function () {})[functionName];

The first version of the code generated by Babel is obviously semantically correct, but the second version isn’t due to the function expression being defined inline as an argument to the _defineProperty utility function.

Has this bug been addressed before?


- Jonathan


  • Babel version(s): v7.5.5
  • Node/npm version: Node 12.7.0/npm 6.10.2
  • OS: OSX 10.14.5
  • Monorepo: no
  • How you are using Babel: cli

This comment has been minimized.

Copy link

commented Aug 7, 2019

Hey @jonathanmarvens! 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.


This comment has been minimized.

Copy link

commented Aug 7, 2019

Function names are one of the parts that we are not really compliant. There has been similar issues like #10175 and #9562

When the property value is an anonymous function, the function name is set by Runtime Semantic NamedEvaluation (§, § It is not a static semantic so in principal babel can not always preserve the function .name, especially in your case where property name is an expression.

@JLHwung JLHwung removed the i: needs triage label Aug 7, 2019


This comment has been minimized.

Copy link

commented Aug 7, 2019

@JLHwung Any reason why cases like this one and #9562 can’t be transformed to use a IIFE in the generated code?


This comment has been minimized.

Copy link

commented Aug 7, 2019

@JLHwung Sorry, in my case, using a IIFE the way that I was thinking wouldn’t actually solve the problem due to the property being an expression (as you already pointed out). It would work for #9562 though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.