-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
ref(core): Reduce inboundfilters bundle size #4625
Conversation
size-limit report
|
return true; | ||
/** JSDoc */ | ||
export function _mergeOptions( | ||
intOptions: Partial<InboundFiltersOptions> = {}, |
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 is int
in intOptions
? Could we give this a clearer name?
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.
integrationOptions
, we can make that clearer (internalIntegrationOptions
?)
I tried not to touch the original variables names as much as possible to make it clear how we've migrated from before -> after.
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, got it. Yeah, I think spelling it out is clearer.
And yeah, if you want this to be a pure moving-stuff-around PR and then integrate some of the improvements separately, I think that's fine and I get the reasoning.
import { InboundFilters, InboundFiltersOptions } from '../../../src/integrations/inboundfilters'; | ||
|
||
/** JSDoc */ | ||
function createInboundFiltersEventProcessor( |
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.
It took me a second or third read to totally grok this function, specifically the fact that
a) all of the machinery is only there in aid of the side effect of creating the event processor, and
b) as a consequence, these aren't mocks I need to care about later on in the tests.
It's also not totally clear to me as a reader (yet) why what we want is the event processor rather than a dummy instance of the integration.
I think it would be helpful to add a docstring explaining those things.
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.
It's also not totally clear to me as a reader (yet) why what we want is the event processor rather than a dummy instance of the integration.
This is also a function of the unit testing of integrations being kind of inconsistent.
Will add a doc string
if (_isSentryError(event, options.ignoreInternal)) { | ||
if (isDebugBuild()) { | ||
logger.warn(`Event dropped due to being internal Sentry Error.\nEvent: ${getEventDescription(event)}`); | ||
} | ||
if (this._isIgnoredError(event, options)) { | ||
if (isDebugBuild()) { | ||
logger.warn( | ||
`Event dropped due to being matched by \`ignoreErrors\` option.\nEvent: ${getEventDescription(event)}`, | ||
); | ||
} | ||
return true; | ||
return true; | ||
} |
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.
Rather than passing the option and checking it in _isSentryError
(and it potentially turning effectively into a no-op), I think it would be better to check it here, and not even call the function if the question is made moot by the option's value.
(That said, do you know why we even have this option? It's not documented, and it's not used anywhere in any sentry repo. Could we just get rid of it?)
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.
We use this to drop all SentryError
errors, which is used pretty extensively throughout the codebase. I don't think we want people to turn this off.
For example, we throw a SentryError
if we don't parse a DSN properly.
I think it would be better to check it here, and not even call the function if the question is made moot by the option's value
Great point, will change.
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 don't think we want people to turn this off.
Exactly. And we don't anywhere. What I'm asking is why we need to have an off switch at all.
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.
This is a good question. I'm going to open up a follow up issue - but leave it like this for now.
if (!options.allowUrls || !options.allowUrls.length) { | ||
return true; | ||
/** JSDoc */ | ||
function _isSentryError(event: Event, ignoreInternal: Partial<InboundFiltersOptions>['ignoreInternal']): boolean { |
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.
function _isSentryError(event: Event, ignoreInternal: Partial<InboundFiltersOptions>['ignoreInternal']): boolean { | |
function _isSentryError(event: Event, ignoreInternal: boolean): boolean { |
It's not going to change, so why not just say what it is?
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.
It's not going to change, so why not just say what it is?
It's to communicate intent - the whole purpose of aliasing types.
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.
Three more, same idea as above.
|
||
/** JSDoc */ | ||
function _isDeniedUrl(event: Event, denyUrls: Partial<InboundFiltersOptions>['denyUrls']): boolean { |
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.
function _isDeniedUrl(event: Event, denyUrls: Partial<InboundFiltersOptions>['denyUrls']): boolean { | |
function _isDeniedUrl(event: Event, denyUrls: Array<string | RegExp>;): boolean { |
(options.ignoreErrors as Array<RegExp | string>).some(pattern => isMatchingPattern(message, pattern)), | ||
); | ||
/** JSDoc */ | ||
function _isAllowedUrl(event: Event, allowUrls: Partial<InboundFiltersOptions>['allowUrls']): boolean { |
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.
function _isAllowedUrl(event: Event, allowUrls: Partial<InboundFiltersOptions>['allowUrls']): boolean { | |
function _isAllowedUrl(event: Event, allowUrls: Array<string | RegExp>;]): boolean { |
return false; | ||
} | ||
/** JSDoc */ | ||
function _isIgnoredError(event: Event, ignoreErrors: Partial<InboundFiltersOptions>['ignoreErrors']): boolean { |
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.
function _isIgnoredError(event: Event, ignoreErrors: Partial<InboundFiltersOptions>['ignoreErrors']): boolean { | |
function _isIgnoredError(event: Event, ignoreErrors: Array<string | RegExp>;): boolean { |
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.
Although this may make that specific line, I like using the alias here, it makes things more consistent. Readers can scroll to the InboundFiltersOptions
above and see the type exactly.
The alias makes the intent of the function very clear, and also communicates how exactly this function is being used - which I think is worth the extra search step a reader has to do to find the exact type.
My rationale here applies for the suggestions below.
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.
All right - agree to disagree on this one.
I'm definitely with you that communicating intent and correct usage is important - that's why I'm pretty religious about adding full docstrings everywhere. When it comes to types, though, what I'm generally going for is ease of reading and the ability to understand quickly what something is - so that scrolling you mentioned is precisely what I'm trying to avoid.
(To be fair, it's not just you - I take issue with derived types in general. To me they're a tool of absolute last resort, and I only use them when I've utterly failed to get TS to accept any other, more direct description, and finally give up and say, Okay, TS, if you're going to be so difficult about it, you figure it out.)
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.
All of the above said - if we are going to keep it as derived types, I don't think we need the Partial
, do we?
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.
You're right, we can remove the Partial
usage.
This makes the tests a lot cleaner. Nice! |
adc13ba
to
ecb6460
Compare
As part of centralizing and unifying our CDN rollup config, this uses the config generation function introduced in #4650 to generate the config for all browser bundles. Unlike many of the other PRs in this series, this one does actually have an effect on certain bundles, to wit: - `_mergeOptions` is no longer a protected-from-minifcation property, as it's about to be extracted into a stand-alone function. (See #4625.) - Up until this point, one difference between the `@sentry/browser` rollup config and all of the other rollup configs was the former's use of the `__SENTRY_NO_DEBUG__` flag to suppress logs in the minified bundles. Rather than add a parameter to the function controlling whether or not each package should use the flag, I decided it was better to just apply the flag to all minified bundles.
As part of centralizing and unifying our CDN rollup config, this uses the config generation function introduced in #4650 to generate the config for all browser bundles. Unlike many of the other PRs in this series, this one does actually have an effect on certain bundles, to wit: - `_mergeOptions` is no longer a protected-from-minifcation property, as it's about to be extracted into a stand-alone function. (See #4625.) - Up until this point, one difference between the `@sentry/browser` rollup config and all of the other rollup configs was the former's use of the `__SENTRY_NO_DEBUG__` flag to suppress logs in the minified bundles. Rather than add a parameter to the function controlling whether or not each package should use the flag, I decided it was better to just apply the flag to all minified bundles.
Changed to remove the type alias |
Hmm idk what's going on with size-bot. Any ideas? |
Size bot fixed itself 🙏 |
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.
Big fan of this PR. Left some optional action items. The one on the ignoreInternal
arg would be really nice to have.
} | ||
return false; | ||
/** JSDoc */ | ||
export function _mergeOptions( |
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.
(optional) Wondering if we should drop the underscore in the extracted function 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.
I'll leave it here for now, but I'll remove the JSDoc as per your comments below.
I left it with the underscore initially to minimize the diff, and make it clear as possible how the functions moved.
if (!options.allowUrls || !options.allowUrls.length) { | ||
return true; | ||
/** JSDoc */ | ||
function _isSentryError(event: Event, ignoreInternal?: boolean): boolean { |
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.
Can we get rid of the ignoreInternal
argument? It seems unrelated to what the function is saying it does.
The if (_isSentryError(event, options.ignoreInternal)) {
above would become if (!options.ignoreInternal && _isSentryError(event)) {
. Might even save some bytes 🤔
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.
Good change, will do!
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 for implementing my feedback!
Had this branch lying around for a while, went back and cleaned it up
InboundFilters
into their own standalone functionsallowUrls.length
instead ofoptions.allowUrls.length
(can't minifyallowUrls
in the 2nd option)typeof self
logic since now we explicitly pass everything in