We are experimenting with migrating the Sentry JS SDK codebase from rollup to rolldown, and while it works for the most part, a common issue we are seeing is a named export is getting added without being defined.

You can find one of those failed tests here failing for sveltekit bundling.

For now, these are my observations from taking a look at both rolldown and rollup outputs and linked possibly related issues:

• Unnecessary variables declarations: Some variables get declared but are never used (e.g: index_server_exports) [Bug]: Unexpected undefined variable is exported for code with export * from ... #6017 [Bug]: Unexpected namespace index_d_exports in generated output #6158
• Those don't then get exported, but variables with similar names get exported instead, but they are undefined so they break builds.

server/index.mjs

// Stuff...

// ⚠️ Was never defined by user code or rolldown, crashes builds
export { server_exports };

index.server.mjs

// ⚠️ That export isn't defined
import { server_exports } from './server/index.mjs';


// ⚠️ This gets declared, never used
//#region src/index.server.ts
var index_server_exports = /* @__PURE__ */ __export({
  //...
});
//#endregion

For our configurations, trying out preserveEntrySignatures="allow-extension" or strict has no effect, we also set preserveModules to true and preserveModulesRoot to src, changing any of those has no effect.

I investigated a little bit and noticed that the second re-export is the one that breaks it, this is because we are working around a Vite issue that puts those exports at the default export rather than named ones.

// server/index.mjs
export {
  addBreadcrumb,
  addEventProcessor,
  // also everything else
} from '@sentry/node';

// This re-export breaks it!!!
export * from '@sentry/node';

Removing the re-export or using export type * ... instead works and produces a valid bundle.

I know the Sentry codebase is too big to pinpoint the issue with all of these custom configurations, so here is a minimal example that demonstrates the issue:

https://repl.rolldown.rs/#eNrdU0Fu2zAQ/MqaFyWFI7mHXlS4KArkWLRIeyt7oKVVwkQihSVlOxD09yxFKbbjJA+IIEDC7M5wOYPtRSXyXmhT4j51SFuk1LsAGZGfwUtRMIr71pKHT1CRbSBJs9iQfJWGO1DknjocloJsXZd2Z9LCmkrfHum+UonSuhml/WOL0MPN1Par9doaB8N04kxPpJFmmqbESnW1h4seVKthuMzP6Otv0EsDQOg7MvEfoCUc5782nh7/6FujuIouh0TVtd1d4d6jcSyQLMNxgWI733Y+nxUOGj9t2dWBGxzg9lerN9YyVwpHhRTPTZWlRjGeoGv4XgEapmKYgIyqc/g3d0vx3WEYODO2RCki/j98Bmn4lSbL4K9ueRa2Ix2DjFSA9XoNaqe0h2j3xcHQy5EXn8Bjc5F0w0ep+h1edtwXRMQUf9fOEd+fhH+Cx+jfTvKN4M5S+HgWxsXK4hoe1uclfLKWox2qLH8QqrKgrtmMHjByvWXx32QLdM4So/M+HRsRtjje/E472LDIgwPtF4vFc0Dz4p/SxMADb3mOz+kqXV1t0Kv0y0oMT8//dCA=

Is this a bug or is it something we should be aware of when using rolldown? re-exporting should be fine in esm AFAIK