build folder is missing in 7.0 beta

Is there an existing issue for this?

I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
I have reviewed the documentation https://docs.sentry.io/
I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/browser

SDK Version

7.0.0-beta.1

Framework Version

No response

Link to Sentry event

No response

Steps to Reproduce

Open https://unpkg.com/browse/@sentry/browser@7.0.0-beta.1/

Expected Result

I should see a build folder as in current stable release https://unpkg.com/browse/@sentry/browser@6.19.7/build/

Actual Result

only non UMD distribution are available as ism and cjs

@jmfrancois

Hi, @jmfrancois.

Thanks for writing in. To my knowledge, use of our SDK through CDNs other than our own has never been a supported use case. The SDK is available on our own CDN, and on npm. More information can be found here.

@lobsterkatie

@lobsterkatie unpkg.com is just exposing the content from npm so the one that is published.
I just want to be sure you will continue as before to publish the bundle on npm which is not the case with latest 7.0 :/

From version 7 onwards we stopped publishing CDN bundles on npm. Only cjs and esm code will live there. We recommend using the Sentry CDN or building the bundles yourself.

unpkg.com is just exposing the content from npm so the one that is published.

Yes, I understand, and I apologize, I should have been clearer. I know that it has worked in the past, and how, but it was never an officially-supported way of getting the SDK, and not one we're maintaining in v7.

I'm going to close this, as the SDK is working as it should, but please feel free to let us know if you're having trouble using the Sentry CDN or our npm packages.

Hi! I would encourage the Sentry team to reconsider this decision. We rely pretty heavily on Dependabot keep dependencies up-to-date across all of our active client projects. This works because client-side library maintainers either include bundles in their published packages or use postinstall scripts to build them for you on installation.

The decision to omit bundle files from the published package puts teams who wish to use said bundles in the position of having to hard-code version numbers in a template or configuration file somewhere in their project, which in turn makes it harder to stay abreast of the latest/greatest features and bug/security patches Sentry has to offer.

Having said all of that, our team put together a best of both worlds solution that uses Sentry’s CDN using the version of @sentry/browser tracked in our project’s package.json. Sharing it here in case someone in a position similar to ours is, like us, not satisfied with having to hard-code a version number in a CDN URL.

I still find myself under an awkward situation where those classic web pages requires CDN version of Sentry and Sentry-provided CDN is not accessible at all. Previously a mirror of CDNJS was used which depends on serving the NPM build dir, and after the build dir is gone the CDNJS is down as well.

Hopefully Sentry team will reconsider this decision. I fail to get the principle behind this change when it is really a common practice demonstrated by other libraries to host built IIFE file on NPM.

Just ran into the same issue, is there any instructions on building the bundles yourself?

@oizik

@oizik That's an excellent question. There is no documentation on it in this repo's README, so I can only assume building it yourself is not an officially supported use case, despite being suggested in this thread.

That said, judging by the package.json file at the root of this repo, one could assume running npm run build:bundle or yarn build:bundle (depending on which package manager you use) would yield the appropriate build files. Personally, I would avoid building files myself because if there is ever a bug that breaks that build command or if Sentry changes the command name, my builds could be impacted and I don't need the hassle of attempting to debug someone else's build system, nor having to file a bug report for it when it is clearly an internal tool that's not meant for my use.

Again: the real solution here is to add bundles back into the Sentry releases. It is a standard practice commonly found among client-side libraries intended to just work with a script tag (as these bundles clearly are). This is how the vast majority of websites include third-party scripts on their pages, and many of the teams maintaining those sites have good reasons not to load them from a CDN. Removing bundles from Sentry's releases feels like a step in the wrong direction, and a puzzling one at that.

@agarzola

@agarzola I couldn't agree with you more. It does make things easy, especially when one can simply include the bundle in gulp build file for example. Was just flicking through our package.json in the project I am working on, and pretty much every package has a dist folder with bundles, including Alpine.JS, Axios, ApexCharts, just to name a few.

Having a look through the @sentry/* folders under node_modules, and reading Restructuring of Package Content I am wondering if it maybe easy enough to use something like Rollup to create the bundles from either cjs for esm folders?

+1 to reconsider this decision. It effectively breaks the NPM-based webjars which are very convenient to self-host the Sentry assets from JVM-based apps.

+1

This was a terrible decision for technical reasons, to summarize my thoughts..

The latest version loader is inherently incompatible with a strong Content-Security-Policy in a security focused web application. When loading JS from other people's servers the only secure way to do it in to specify an exact hash of the contents so it will fail if it's ever modified.
If I embed links to a specific version on your CDN, I lose the benefit of npm telling me when updates are available, as well as npm audit knowing which version we use. Same problem if I mirror the bundle from your CDN to my own server.
Your CDN has recorded outages, if I self host the bundle I'm guaranteed that if my server is online all my JS will load. I also know that if a user can reach my network and not your CDN they'll get all the JS to run the application. If Sentry is the first executed javascript (and it needs to be to ensure all errors are caught), then a Sentry CDN outage can cause an outage for my application. This is not a hypothetical scenario: Been receiving 404s for loader bundle #10331

This decision is causing real harm to the security and reliability of applications.

docs: Add docs on building the SDK (#10368)

One benefit that you get from consuming the npm package directly is that you can use a bundler to treeshake out unused code. Solutions like webjars, loading straight from unpkg, even our own CDN bundles we offer will end up with you loading dead code because on unused SDK features. Is that cost worth it?

We added some docs about building the SDK here - #10368, but I would really recommend just using something like vite/esbuild to make sure that you only include what exactly you need. You also get the added benefit with using your own bundlers because you can use treeshaking flags to include just the features you care about!

Otherwise you should be able to take SDK output -> take all the exports you care about -> publish a mini SDK bundle with just the stuff you need. This also allows you to easily mix and match with @sentry/integrations, @sentry/utils, or hand written sentry integrations, in case you need optional integrations like HTTPClient.

// sentry.js
export { init, ... } from "@sentry/react" // or browser, vue, svelte, angular
export { HttpClient, ... } from "@sentry/integrations";

Then with esbuild for example

esbuild --define:__SENTRY_DEBUG__=false sentry.js --bundle --outfile=sentry-bundle.js

And you should be able to upload that sentry-bundle anywhere - you could even publish it to npm yourself if you want!

The Sentry SDK now has many different features, errors, performance monitoring, profiling, session replay, metrics, and user feedback. Maintaining bundle permutations (and all of their typedefs) for all those features for our 15+ browser js SDKs (react, sdk, vue, angular, etc.) is a huge maintenance cost for us, and would spike average npm download size for every single one of our js sdk users (whole lot more bytes across the wire).

Your CDN has recorded outages, if I self host the bundle I'm guaranteed that if my server is online all my JS will load

To follow up on this specifically, I apologize for the trouble caused here. #10331 was a one off by a change made as part of our EU region initiative. Otherwise our CDN and loader typically have high reliability, but I recognize we probably need to be more open about that. I created #12847 to track having a more formal SLO for our provided CDN/loader bundles that we display somewhere (maybe on status.sentry.io)

Your CDN has recorded outages, if I self host the bundle I'm guaranteed that if my server is online all my JS will load

To follow up on this specifically, I apologize for the trouble caused here. #10331 was a one off by a change made as part of our EU region initiative. Otherwise our CDN and loader typically have high reliability, but I recognize we probably need to be more open about that. I created #12847 to track having a more formal SLO for our provided CDN/loader bundles that we display somewhere (maybe on status.sentry.io)

In my case "typically have high reliability" isn't good enough, so you're basically making using Sentry for us much harder than it needs to be.

Navigation Menu

Repository navigation

build folder is missing in 7.0 beta #5108

Is there an existing issue for this?

How do you use Sentry?

Which package are you using?

SDK Version

Framework Version

Link to Sentry event

Steps to Reproduce

Expected Result

Actual Result

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

build folder is missing in 7.0 beta #5108

Description

Is there an existing issue for this?

How do you use Sentry?

Which package are you using?

SDK Version

Framework Version

Link to Sentry event

Steps to Reproduce

Expected Result

Actual Result

Activity

lobsterkatie commented on May 16, 2022

jmfrancois commented on Jun 6, 2022

lforst commented on Jun 7, 2022

lobsterkatie commented on Jun 7, 2022

lobsterkatie commented on Jun 7, 2022

agarzola commented on Jul 12, 2022

wfjsw commented on Sep 6, 2022

oizik commented on Mar 12, 2023

agarzola commented on Mar 12, 2023

oizik commented on Mar 12, 2023

metametadata commented on Jul 17, 2023

futurewebpn commented on Sep 3, 2023

anthonyryan1 commented on Jan 26, 2024

AbhiPrasad commented on Feb 2, 2024

AbhiPrasad commented on Feb 2, 2024

antonpodolsky commented on May 12, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions