export * from './some-file' in library breaks tree-shaking ability

[benoitgrelard]

🐛 bug report

It seems Parcel2 breaks tree-shaking ability when export * from … is used.
This used to work for us with Parcel1, all we've done is upgraded to Parcel2.

🎛 Configuration (.babelrc, package.json, cli command)

No special config, all stock straight out of parcel2

🤔 Expected Behavior

I would expect that using export * from, the exports would still be statically analysable because all these types of exports in ESM are static.

😯 Current Behavior

It breaks tree-shaking and all the members of the modules are included, even unused ones.

💁 Possible Solution

I wonder if it's because Parcel now operates at the string level, rather than AST, and therefore it cannot "see" what's exported from the file when we do export * from ….

🔦 Context

This has broken tree-shaking in https://github.com/radix-ui/primitives since we moved to parcel2.

💻 Code Sample

I've narrowed this down to its most basic form and made a video of it.
Don't forget to turn the sound 🔊 on as I explain the situation:

CleanShot.2022-06-15.at.14.22.40-converted.2.mp4

---

To summarize, if top-level library file is:

export { add, multiply } from "./number";

Then the module output for it looks like this:

function $2166fc5bbb34ad18$export$e16d8520af44a096(a, b) {
    return a + b;
}
function $2166fc5bbb34ad18$export$2060d2db72cce88f(a, b) {
    return a * b;
}

export {$2166fc5bbb34ad18$export$e16d8520af44a096 as add, $2166fc5bbb34ad18$export$2060d2db72cce88f as multiply};

however

If the top-level library file is:

export * from "./number";

Then the module output for it looks like this:

function $parcel$export(e, n, v, s) {
  Object.defineProperty(e, n, {get: v, set: s, enumerable: true, configurable: true});
}
var `$2166fc5bbb34ad18$exports` = {};

$parcel$export($2166fc5bbb34ad18$exports, "add", () => $2166fc5bbb34ad18$export$e16d8520af44a096);
$parcel$export($2166fc5bbb34ad18$exports, "multiply", () => $2166fc5bbb34ad18$export$2060d2db72cce88f);
function $2166fc5bbb34ad18$export$e16d8520af44a096(a, b) {
    return a + b;
}
function $2166fc5bbb34ad18$export$2060d2db72cce88f(a, b) {
    return a * b;
}

export {$2166fc5bbb34ad18$export$e16d8520af44a096 as add, $2166fc5bbb34ad18$export$2060d2db72cce88f as multiply};

🌍 Your Environment

Software	Version(s)
Parcel	2.6.0
Node
npm/Yarn
Operating System

[devongovett]

Reproduction

[devongovett]

Investigated a little but can't spend more time on it right now.

The re-exported asset has its usedSymbols set to '*' here. The packager checks that here to determine whether to add the namespace object. I guess perhaps symbol propagation should expand the '*' symbol to the actual symbols in usedSymbols for re-exports. I tried to do this but failed some tests. Symbol propagation code is quite complex, so might need some help.

[greevz]

This is also affecting us. I've recently migrated over to Parcel from Webpack, and noticed our bundle sizes were double the size because of this exact issue.

[stoompa]

Is someone working on this? Is there a workaround? I am experiencing the same issue