Conversation
size-limit report
|
|
|
||
| /** Helper to get Sentry API endpoints. */ | ||
| protected readonly _api: API; | ||
| protected readonly _api: APIDetails; |
There was a problem hiding this comment.
I think this is okay but generally I think this design still makes it hard for us to make improvements later. Unfortunately the subclassing situation will always be bad for minification but quite user friendly for custom transports, so it might be acceptable to do it this way.
In Python as an example we push the original options in (there are no transport options) and the transports pull from there what they need. We should probably not change this right now, but longer term I think that might be preferable here as well.
There was a problem hiding this comment.
I completely agree - but we can revisit this when we examine transports more holistically later on. I kept this pattern primarily to minimize the diff and possibilities for breakage.
original options in (there are no transport options) and the transports pull from there what they need
This is the direction we should head in, actually we might be able to pull it off before the major
2 participants
Trying to minimize behaviour differences until we properly refactor the transports as per
Extract out transports into their own modulesin #4240