-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
__name is not in scope if a class is stringified. #1438
Comments
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. |
This scenario is not supported by esbuild. See https://esbuild.github.io/content-types/#function-tostring for more information. |
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 ^^;) |
This is problematic in more cases than just Closing since this is an unsupported use case. |
I understand this use-case is not supported, but wanted to share an unfortunate scenario where this is also problematic: |
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. |
This is problematic in |
Related to #1437, a function in code:
becomes:
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 likeadd
above does not need to have .name property if it did not have one in code.The text was updated successfully, but these errors were encountered: