-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
ref(node): Small RequestData integration tweaks
#5979
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
Conversation
size-limit report 📦
|
|
|
||
| /** | ||
| * 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
RequestDataintegration: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
RequestDataOptionstype toRequestDataIntegrationOptions, to help distinguish it from the many other flavors of request data functions and types floating around.Make all properties in
RequestDataIntegrationOptionsoptional, rather than using thePartialhelper 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
AddRequestDataToEventOptionsfrom 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
includeoption for use inaddRequestDataToEventto 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
includeproperty, in order to have access to thetransactionNamingSchemeoption.Add missing
transactionproperty in helper function's output.Add tests for the helper function.