Unneded functions renaming, keepNames and polyfills #1147
Comments
|
Good |
|
I wonder how much, if any, of public api is affected by this. Pinging @evanw. It would be important to know your take on this. Unneeded renaming of function names can be a significant bug in itself for library authors. |
|
@evanw it's still a block for |
|
I come from Webpack, and after seeing the esbuild build code I was surprised find all the code at the same level. // func1.js
export function Func() {}// func2.js
export function Func() {}// index.js
import * as Func1 from "./func1";
import * as Func2 from "./func2";
console.log(Func1.Func.name); // Func
console.log(Func2.Func.name); // Func2// esbuild-out.js
(() => {
// func1.js
function Func() {
}
// func2.js
function Func2() {
}
// index.js
console.log(Func.name);
console.log(Func2.name);
})(); |
|
|
|
@juanrgm it does not work in old engines (FF <38, Chrome <43, Safari <10) where |
|
If I choose to prevent my function names from renaming (from adding a digit at the end of its name) at any cost, where do I set for working only with the engines (browsers) where it is "configurable" or "compatible"? Thanks! |
|
However, the question is - why does esbuild rename the functions at all? Can it keep the names of the functions as they are? What is the class of bugs that this renaming fixes? |
One example: Two files might each have a top-level function declaration with the same name. If esbuild didn't rename one of them then one would overwrite the other. |
|
@evanw I see, but when files are not bundled - there is no conflict that could happen, right? |
|
In addition to that, I see that the files in our bundle are wrapped in either var init_BaseConversationListItem = __esm({
"ts/components/conversationList/BaseConversationListItem.tsx"() {
// here comes the function that is renamed
}
});It sounds like top-level declarations can't really conflict for such modules because they are bound to the scope of the module. |
|
@evanw
transformed to
This named function |
When we are renaming variables - we don't need to check for the conflicts past the closest scope that stops the hoisting. Additionally, function expression's name should be put into function's scope, and not outside of the function. Fix: evanw#1147
|
Just a short update, I've opened a PR to fix this: #2042 |
When we are renaming variables - we don't need to check for the conflicts past the closest scope that stops the hoisting. Additionally, function expression's name should be put into function's scope, and not outside of the function. Fix: evanw#1147
When we are renaming variables - we don't need to check for the conflicts past the closest scope that stops the hoisting. Additionally, function expression's name should be put into function's scope, and not outside of the function. Fix: evanw#1147
When we are renaming variables - we don't need to check for the conflicts past the closest scope that stops the hoisting. Additionally, function expression's name should be put into function's scope, and not outside of the function. Fix: evanw#1147
|
Hey, it's still one of the fundamental issues why I can't move some |
I tried to move the building process of
core-jstoesbuildand found unneeded renaming of some function names.This renaming is definitely unneeded since functions with the same names are defined in disjoint closures.
The
keepNamesoption can't be applied here since in many old engines we can't redefine functions.nameproperty - it throws an error.It can't be prevented anyway in case of polyfilling and usage of polyfilled features in one bundle.
And it's dangerous. Even if
core-jswill not useesbuildfor bundling by itself, someone will bundle projects withcore-js- it's used on most websites.core-jspolyfills many fundamental builtins and after this renaming, for example,Number.namewill be"Number2"- I remember some libraries which it will break.The text was updated successfully, but these errors were encountered: