-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(astro): Ensure server-side exports work correctly #12453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super odd
Thank you for the quick action! If this behavior is specific to Astro (or maybe Vite used by Astro), do you think it should be reported upstream? |
To be honest, I'm not sure - it might also be related to our end, how we declare entry points in the Before we report this, we'd need to figure out a minimal reproduction and take Sentry out of the equation as much as possible. |
Our "consistent node exports" e2e test just caught a bunch of additional missing exports for this change. Added them in cc1b529 |
size-limit report 📦
|
This PR fixes a server-side re-export problem of
@sentry/node
exports in the Astro SDK.Previously, our emitted ESM
index.server.js
file would contain these two re-exports:Unfortunately, it seems that with recent Astro (or SDK?) versions, this caused Sentry imports in
.astro
files to resolve toundefined
rather than to their actual exports:It seems that the
export * from '@sentry/node'
"overruled" the explicit exports. So this PR changes our export statements to:*
export in the types entry pointfixes #12410