Repository navigation
@sentry/webpack-plugin Adds Code That Breaks Old Browsers #769
Description
Activity
Hey @grushetsky thanks for writing in! The decision to drop ES5 support was made intentionally in version 3.0.0 of the plugin (see changelog). Given this does save a little bit of bundle size and the overall decline of ES5, I think we'll keep it this way for now.
If you need ES5 support, I suggest trying
@sentry/webpack-plugin@^2for now. Let me know if you're missing a feature on this version.Side note: If there is a blocker in using the older version, I think alternatively, we can consider adding back ES5 compatibility as an opt-in mechanism (similarly to what was propsed in #610 (comment), when we tried simplifying the global object lookup). For now though, I want to avoid this if we don't have to do it.
Reacted by Konstantin Grushetsky- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Jul 22, 2025 Hey, @Lms24! Thank you for the feedback!
ES5 is being phased out, which is a good thing. The problem is that most of the Smart TV platforms (like Samsung's Tizen and LG's webOS TV) do not update their browser engines that run apps. At the same time the userbase of these devices remains relevant for developers and vendors.
@sentry/webpack-pluginversion 2.x had some issues with source map uploading as far as I remember. I could try to test it out once more, but it seems suboptimal to use this version. First of all, it is unlikely that the version 2.x is going to receive updates, so, it's not a futureproof solution. Second, in order to have the most optimal bundle I need separate builds (targeting both ES5 and ES2015+ environments), thus, I need to use two versions of the same library, which is solvable, but is also cumbersome. It adds complexity to the config.I think that
targetEnvironmentoption for the plugin would be the best approach here. As ES2035 comes around, Sentry will already have the option.Are you OK if we add this or similar option to
@sentry/webpack-plugin?@grushetsky thanks for explaining your use case!
Are you OK if we add this or similar option to @sentry/webpack-plugin?
Before you invest more time here, let me bring this up with the team to get some more opinions. I'll get back to you.
In the meantime, just to clarify: Do you have an option to polyfill missing features for your target language level? Usually our code should be added to the build early enough for tools like babel to come in. Also worth noting that our SDK code isn't transpiled to ES5 anymore since a long time. See browser compatibility. So either you're using a very old SDK version or you're adding polyfilles already?
Reacted by Konstantin Grushetsky- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Jul 22, 2025 Before you invest more time here, let me bring this up with the team to get some more opinions. I'll get back to you.
@Lms24, thanks!
Do you have an option to polyfill missing features for your target language level? Usually our code should be added to the build early enough for tools like babel to come in. Also worth noting that our SDK code isn't transpiled to ES5 anymore since a long time.
I do use polyfills for the project (
letcan't be polyfilled though as you know). There is also a transpilation phase in my build pipeline that downgrades the syntax (includinglet) for Sentry. The problem is that the troublesome code is defined as a string, so it can't be modified by the transpiler. And as I could observe this code is injected into the app's scripts by the plugin after the transpiler (a webpack loader) does its job.If we change the moment when this code is injected into the scripts, so that it can be processed by the transpiler, then we will have no issues. This will probably be the best solution. It avoids introducing an extra configuration option and it also fixes Sentry usage on old platforms. Do you think that we can adjust the moment of code injection?
Hey @grushetsky thanks for letting us know about the timing issue! Admittedly, I thought that the
transformhook (or whatever unplugin tanslates this to for Webpack) came in early enough for Babel to apply but apparently that's not the case for actual transformation (as you pointed our forlet->var).If we change the moment when this code is injected into the scripts, so that it can be processed by the transpiler, then we will have no issues.
This would be an option, but in fact we're trying the opposite -- move it to
renderChunkhook which comes in later in the build lifecycle. The benefit we expect with this is that memory consumption should decrease (specifically, all our transforms have to be source mapped and these maps eat up memory) and performance (as we'd apply the transform once per chunk instead of injecting the snippets into almost every file before they're bundled). More details in #761.So after discussing this internally, we decided to actually go with your suggestion and just make the snippets ES5 compatible in the first place. The bundle size overhead isn't that bad and it provides the broadest compatibility. I will reopen your PR and give it a proper review in a bit.
Thanks for being patient and sorry for the back and forth!
Reacted by Konstantin Grushetsky- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Jul 23, 2025 @Lms24, no problem. Thank you for the detailed explanation!
Environment
Chromium 38,
@sentry/webpack-plugin3.5.0.Steps to Reproduce
@sentry/webpack-pluginincluded in the list of plugins.Expected Result
The app starts up without errors.
Actual Result
A syntax error near
letkeyword is thrown upon app start.Additional Details
Sentry injects some code that has
letin it.letsyntax is not supported by the old browsers.