-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(vue): Deprecate configuring Vue tracing options anywhere else other than through the vueIntegration
's tracingOptions
option
#14385
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
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
4e1c8af
feat(vue): Deprecate configuring Vue tracing options anywhere else ot…
lforst 1a730e3
Merge remote-tracking branch 'origin/develop' into lforst-vue-tracing…
lforst 57a0cb4
test
lforst 70b589e
Merge remote-tracking branch 'origin/develop' into lforst-vue-tracing…
lforst File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
the only thing we could think about elevating to root-level config IMHO is
trackComponents
, this seems somewhat important enough to possibly warrant this (and also should not be too confusing). So IMHO we could still allow this specifically to also be passed directly toinit()
, in addition to allowing to pass it to the integration, but no strong feelings.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 also admittedly don't have hard feelings towards this. I would err towards not allowing it top-level because it opens the door for things tree-shaking in the future, and less ambiguous docs.
@Lms24 @s1gr1d do you have opinions on whether or not we should still allow
trackComponents
as a top-levelSentry.init()
option?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'd prefer keeping it integration only because if
Sentry.vueIntegration
is filtered out, thentrackComponents
doesn't do anything.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 am with Abhi on that, but in Nuxt the
vueIntegration
is added by the SDK not the user, so I would have to introduce an option in the Nuxt SDKinit()
which still allows overriding thevueIntegration
options.Something like
vueOptions
?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 opened a PR to update the docs. That will maybe highlight a bit better what the config will look like: getsentry/sentry-docs#11917
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.
Component tracking options are mostly defined outside the Sentry.init options across our SDKs. I think it's fine to only have them at integration level in Vue. For Nuxt, we probably want to figure out a way of still letting users change things but I'd argue this is a long-term goal. AFAIK, we don't have docs on component tracking in meta framework SDKs at all at the moment.
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 I see how you envisioned it for Nuxt - users add the
vueIntegration
themselves. However, I think that would not work here, as the Nuxt SDK already adds thevueIntegration
internally to setup the Vue router. This happens here:sentry-javascript/packages/nuxt/src/runtime/plugins/sentry.client.ts
Line 56 in 472c228
It happens at this place in the Nuxt SDK as we need to pass the
vueApp
and this is the earliest place to do so (the user cannot pass it).So we would still have to add something like a
vueOptions
key for the Nuxt SDKinit
as we cannot call the integration twice.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 think that's fine