search

bugsnag / webpack-bugsnag-plugins

Webpack plugins for common BugSnag actions.
MIT License
32 stars 29 forks source link

Add transformSource option #30

Closed isBatak closed 5 years ago

isBatak commented 5 years ago

Fix issue in task #3

snmaynard commented 5 years ago

It looks like the issue you linked to says this is no longer a problem in Next 7. Are you using an older version of Next or is there some reason that you believe it not to be fixed in Next 7? Thanks!

isBatak commented 5 years ago

@snmaynard I explained it here https://github.com/bugsnag/webpack-bugsnag-plugins/issues/3#issuecomment-475431000 I believe issue #3 is not fixed, at least not completely.

snmaynard commented 5 years ago

Are you saying that the following is not true?

As next now stores the files in the same path that their served to the client.

I'm not super familiar with Next, looking at their docs it implies that a BUILD ID is always added to the path and is randomised on each build, even with Next 7. However each BUILD ID would/should upload new sourcemaps to bugsnag as the code may be different - so I'm not sure why you would want to wildcard match across builds?

isBatak commented 5 years ago

As next now stores the files in the same path that their served to the client.

This is true, but it is not a problem. Problem is that I don't want to accumulate old source maps over time. Each new build will generate new BUILD_ID and source URL will be different, because of that option overwrite: true won't work. If we add a wildcard in place of BUILD_ID on each build source maps will be overwritten.

snmaynard commented 5 years ago

Problem is that I don't want to accumulate old source maps over time.

By this do you mean that you don't want to accumulate old source maps in Bugsnag? How comes?

isBatak commented 5 years ago

Why would I want that? EDIT: ... to accumulate source maps of the old builds on bugsnag server?

snmaynard commented 5 years ago

Why would you not? It means that it works when people are still on old URLs, or when events haven't been processed by bugsnag yet the sourcemaps are still applied.

When we roll out retroactively applying sourcemaps to existing events in your dashboard upon upload this could cause us to break all your stacktraces because you have told us use this new sourcemap for this URL.

We are going to automatically age off unused sourcemaps in future but it's not a priority at the moment. Is the reason that you don't want them in Bugsnag any more a cleanliness thing or is there some other reason I'm not accounting for?

isBatak commented 5 years ago

When we roll out retroactively applying sourcemaps

Isn't that a bad idea? What if some setups don't have a unique ID in the URL and always release the same file but different source, retroactive apply of source maps will break things...

It was mainly because of cleanliness, and because we have a project that produces 70 source maps for client and 70 for server-side code (code splitting), and when you multiply it with 2 environments (staging and production) plus frequent deploys (almost every day for staging) it could get very messy with the storage space. Is there any limit regarding the storage?

What would be the use of overwrite: true then?

snmaynard commented 5 years ago

There is no limit on our side for storage. We will start to age off old sourcemaps in the future but we'll do that when the storage size becomes large enough to warrant spending time on that.

The intent behind overwrite: true is to correct a mistake when you upload a sourcemap for a URL incorrectly. Otherwise we return early from the endpoint letting you know we already have that sourcemap.

isBatak commented 5 years ago

Ok, then we have no problem :D I'll close the PR! Thx!

snmaynard commented 5 years ago

np - thanks for answering my qs!

Isn't that a bad idea? What if some setups don't have a unique ID in the URL and always release the same file but different source, retroactive apply of source maps will break things...

This is one of the reasons that we haven't done this yet. We do allow people to use app_version as well as URL - so you could increment the version when changing the code, but I'm not sure that adoption of those practices is high enough yet for us to do this. People are moving towards it for cache invalidation reasons though so one day!