__name is not in scope if a class is stringified.

[yoshikiohshima]

Related to #1437, a function in code:

class Foo {
    foo() {
        let add = (e) => console.log(e);
       add("x");
   }
}

becomes:

var Foo = class {
  foo() {
    let add = /* @__PURE__ */ __name((e) => console.log(e), "add");
    add("x");
  }
};

when bundled with --bundle --keep-names --format=esm options.

However, __name function is not in the scope when the class is stringified by toString() and then eval()'ed again. An anonymous function like add above does not need to have .name property if it did not have one in code.

[navanshu]

You will have to set keep-names to false and __name won't show up in your final code and your program will run fine. If that is what you intentd.

__name beign there seems like a esbuild bug to me. since it has not been defined in the final output by esbuild

If you intent to use keep-names then __name, it is to wrap this function into some other function call. I even don't understand the use case for keep names, it might be a bug.

[evanw]

However, __name function is not in the scope when the class is stringified by toString() and then eval()'ed again. An anonymous function like add above does not need to have .name property if it did not have one in code.

This scenario is not supported by esbuild. See https://esbuild.github.io/content-types/#function-tostring for more information.

[yoshikiohshima]

Okay... It is unfortunate that in my particular use case, those classes and functions obey the rule of not having any references to external variables so that the combination of toString() and eval() is guaranteed to work. It this particular case, esbuild introduces new external references, which to me is non-semantics preserving transformation.. But I understand that for vast majority of cases, esbuild is doing really great job, and it does not have to address an issue in a particular case (which, incidentally, a live collaborative programming environment where that restricted JS code is sent over the network. I kind of like to demo it if there is a change ^^;)

[evanw]

This is problematic in more cases than just --keep-names so changing how that feature is implemented is still a brittle solution and may randomly break in the future, since this is still an unsupported use case and esbuild uses helper functions for other things too. If you still want to use esbuild, you should instead build the source code in a separate build step and then insert it as a string into your code that needs the string.

Closing since this is an unsupported use case.

[privatenumber]

I understand this use-case is not supported, but wanted to share an unfortunate scenario where this is also problematic:
privatenumber/tsx#87

[yoshikiohshima]

Thanks. it would be really great if esbuild does not add new globals and keep the semantics of original code in just a bit more strict sense.

[privatenumber]

This is problematic in playwright in addition to terser-webpack-plugin: privatenumber/tsx#113