-
-
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(node): Small RequestData
integration tweaks
#5979
ref(node): Small RequestData
integration tweaks
#5979
Conversation
size-limit report 📦
|
}; | ||
|
||
/** Whether to identify transactions by parameterized path, parameterized path with method, or handler name */ | ||
transactionNamingScheme: TransactionNamingScheme; | ||
transactionNamingScheme?: TransactionNamingScheme; | ||
|
||
/** | ||
* Function for adding request data to event. Defaults to `addRequestDataToEvent` from `@sentry/node` for now, but | ||
* left injectable so this integration can be moved to `@sentry/core` and used in browser-based SDKs in the future. |
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.
l: this is no longer true right? Shall we update?
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.
Which part is no longer 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.
We are no longer moving the integration to core right? We are just making seperate ones for browser/node.
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.
Wasn't sure if we'd actually decided that or just said, "Yeah, we might end up doing separate ones, so fine to move it back into the node SDK for now." Anyway, I can move it to being a property, so it's not cluttering options but could be overridden by subclassing if we ever get that far.
f1f94c6
to
2ec8261
Compare
2ec8261
to
2e54082
Compare
2e54082
to
9e9ee94
Compare
This makes a few small revisions to the new
RequestData
integration:Switch to using booleans rather than an array of keys when specifying what user data to include. This makes it match all of the other options, and is something I should have just done from the get-go. Given that the integration is new and thus far entirely undocumented, IMHO it feels safe to make what is technically a breaking change here.
Rename the integration's internal
RequestDataOptions
type toRequestDataIntegrationOptions
, to help distinguish it from the many other flavors of request data functions and types floating around.Make all properties in
RequestDataIntegrationOptions
optional, rather than using thePartial
helper type.Switch the callback which actually does the data adding from being an option to being a protected property, in order to make it less public but still leave open the option of subclassing and setting it to a different value if we ever get around to using this in browser-based SDKs. Because I also made the property's type slightly more generic and used an index signature to do it, I also had to switch
AddRequestDataToEventOptions
from being an interface to being a type. See Index signature is missing in type (only on interfaces, not on type alias) microsoft/TypeScript#15300.Rename the helper function which formats the
include
option for use inaddRequestDataToEvent
to more specifically indicate that it's converting from integration-style options toaddRequestDataToEvent
-style options.Refactor the aforementioned helper function to act upon and return an entire options object rather than just the
include
property, in order to have access to thetransactionNamingScheme
option.Add missing
transaction
property in helper function's output.Add tests for the helper function.