-
Notifications
You must be signed in to change notification settings - Fork 700
Description
I tried this on the latest pkgr release to test out the fix to #7115 in #7218
https://pkg.pr.new/rolldown@f4aaab9
While it works for simple chains, I tried a longer export chain with multiple re-exports along the path. If exports name the same module twice, the resultant bundle is invalid as it would declare it twice, once as a let variable and once as a var which would break the bundle.
Again this is with preserveModules: true
Exact Case
We do a combination of start exports along with named exports, the main reason is the behavior that exists in rolldown/rollup that automatically nests all exported names under default.
To simplify the scenario, Assume an external named zod, export transitively from a module, once as named exports and another as a star exports.
export { string, object } from 'zod';
// Server: re-exports from external library
export * from 'zod';Expected Result: Either deconflict the names by giving each one a unique name or let the star export override the named ones, this is valid ES module stuff.
Actual Result: Two variables declared, causing conflicts and a redeclaration error.
const require_rolldown_runtime = require('./_virtual/rolldown_runtime.js');
require('./server.js');
// first declaration, maps to the named exports
let zod = require("zod");
// ...
// Second declaration, maps to the star exports, breaks the bundle
var zod = require("zod");
Object.keys(zod).forEach(function (k) {
if (k !== 'default' && !Object.prototype.hasOwnProperty.call(exports, k)) Object.defineProperty(exports, k, {
enumerable: true,
get: function () { return zod[k]; }
});
});Reproduction
I got a simple reproduction here, with just two files:
Note that it also happens if done at different points of the export chain, which makes it hard to work around, here is an example of a chain:
Also every file in the chain will contain the two variable declaration, causing each file to be invalid as well.
Workarounds, we could just remove all named exports we have that get rexported by a start in the same file, but hard to do/guarantee that for long chains.