Conversation
There was a problem hiding this comment.
Can I see a test where we have --importHelpers and something like:
const obj = {};
const __spread = {...obj};(so there's a local name which takes priority over the helper name)
I'd expect our emit to be something like
import { __spread as __spread_1 } from "tslib";
const x = {};
const __spread = __spread_1({}, x);(where previously no renaming of the helper would be needed, since it was namespaced)
We explicitly don't do this for any helpers, because we allow you to replace helpers. If we renamed a helper because we found a declaration with the same name at the top-level, we would break that feature. |
But that doesn't work for import helpers, because the helper gets imported and accessed via namespace (usually)? |
|
"Rename the helper for all uses of the helper in the file but only if its imported and |
|
I'm just pointing out that previously const x = {};
const __assign = {...x, x: 12};
export {};with |
|
Fair enough. I'll look into it tomorrow. |
|
I've added import aliases for cases where there are collisions. |
Changes the emit for
--importHelperswhen the module kind ises2015oresnextso that they are tree-shakable by WebPack.For example, we previously would emit:
But now we emit:
The emit for
commonjs,amd,umd, andsystemis unaffected.Fixes #16999