-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: Add Sentry to the bundler plugins #224
Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files
☔ View full report in Codecov by Sentry. |
Bundle ReportChanges will increase total bundle size by 10.36kB (0.17%) ⬆️. This is within the configured threshold ✅ Detailed changes
|
Bundle ReportChanges will decrease total bundle size by 30.43kB (-0.48%) ⬇️. This is within the configured threshold ✅ Detailed changes
|
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.
Hey, I heard you were looking for a review from the JS SDK team, so I took a look (also, sorry for the delay!). I think in general, this LGTM. We're taking care of removing stack traces and potential PII and the client/scope handling seems to be mostly in line with the Sentry bundler plugins 👍
Are there specific questions or things you'd like us to look at in detail?
Co-authored-by: Lukas Stracke <[email protected]>
0103d28
to
d04efd9
Compare
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.
Had a couple questions, but looked good!
pluginVersion: PLUGIN_VERSION, | ||
options, | ||
bundler: unpluginMetaContext.framework, | ||
metaFramework: "astro", |
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.
What do these 2 keys represent again? bundler
vs. metaFramework
? On first glance, I would have expected the values to be flipped here with bundler being "astro" and the metaFramework being from the enum from unplugin.
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.
Bundler is the underlying bundler (Rollup, Vite, Webpack), this value is derived from Unplugin itself, whereas the meta-framework value is what we pass through as things like Astro are built on-top of bundlers (Vite in this case), bundlers being the "lowest" system in the stack.
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.
Got it, thanks!
If we can declare an enum or type for the acceptable strings that may be nice in the future.
platform: "node", | ||
runtime: { name: "node", version: global.process.version }, | ||
|
||
dsn: "https://[email protected]/4506739665207296", |
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.
Any thoughts on making a network call to Codecov to fetch this dsn? If we hardcode it here, we won't be able to change it for anyone using old versions of the plugin. Maybe overkill since it will make it slower and add more failure pathways, though.
Do we have any other examples of how it's done around in Sentry as guidance perhaps?
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.
I'd like to avoid any extra calls, as well as the work to maintain an endpoint to distribute this value. Typically for any client based application the DSN is just shipped with the package, this is how it is done for their bundler plugins.
Can you expand upon your concerns around users using older versions of the plugin?
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.
Okay great, good to know that's the usual pattern!
Oh yeah re: older versions of plugin - I mean say version 1 has this DSN hardcoded and that's what they're running. Say a year down the road we need to change the way we configure things and we have a new DSN for our org the old one gets deprecated, and hardcode the new one in version 2. Anyone still on version 1 is broken until they upgrade.
Basically backwards compatibility can potentially be annoying. This is probably overengineering for where we are though so we can go with hardcoding!
packages/webpack-plugin/src/index.ts
Outdated
telemetryPlugin({ | ||
sentryClient: sentryConfig.sentryClient, | ||
sentryScope: sentryConfig.sentryScope, | ||
shouldSendTelemetry: options.telemetry, |
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.
nit: I've lost track a little on why different keys of telemetry
, enableTelemetry
and shouldSendTelemetry
across the different layers. Was it intentional to name them differently? Also should we create and push this plugin into the list at all if it's not enabled? Maybe missing something on that
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.
okay i've gone through and went with telemetry
for everything ... this has been in progress for too long I guess I started coming up with new names 😭
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.
Ah nice, sorry for any trouble.
That looks good!
My other thought in there was buried - what do you think RE: only creating/pushing the plugin into the list if it's enabled (to save running any unneeded code)?
We can do that in a separate pass if we think it's worthwhile
|
||
interface SentryConfig { | ||
sentryClient?: Client; | ||
sentryScope?: Scope; |
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.
nit: thoughts on naming this as client
and scope
since they are already in something named SentryConfig
?
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.
Hrrmrmrmrm, for this one, I think i'll leave it as is, i tend to lean towards more verbose naming. We may be looking at adding in amplitude and if we do there may be more clients (idk about scopes) but this keeps it a bit clearer as to what's going on with these.
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.
Sure sounds good - thanks!
} | ||
debug(`Error uploading stats: "${error}"`, { enabled: this.debug }); | ||
return; | ||
throw error; |
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.
Was it intentional to remove the if (emitError) throw error
check here? It's possible more things will slip through to throw that used to be "swallowed" with this change I think, in case that has any unintended effects.
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.
Uhh this was a newly added in throw, sooooo nice catch and my bad 😅
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.
Oh okay sounds good! I think either way works if we have some errors we treat as more "catastrophic". Adding the check here makes sense - thanks!
}, | ||
}; | ||
}; | ||
} |
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.
nice, these look tricky
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.
#thanks-sentry 💪
Description
This PR adds in the first iteration of Sentry to the bundler plugins, however, this PR does not include adding Sentry to the
bundler-analyzer
as that will come in a following PR as that requires a bit more work to sorted and this PR was getting big enough as it is.Ticket: codecov/engineering-team#954
Notable Changes
Output
to track some initial data points