feat(vue): Deprecate configuring Vue tracing options anywhere else other than through the vueIntegration's tracingOptions option
#14385
Conversation
This file contains 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
…her than through the `vueIntegration`'s `tracingOptions` option
size-limit report 📦
|
mydea
reviewed
Nov 21, 2024
| integrations: [ | ||
| Sentry.vueIntegration({ | ||
| tracingOptions: { | ||
| trackComponents: true, |
There was a problem hiding this comment.
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 to init(), in addition to allowing to pass it to the integration, but no strong feelings.
There was a problem hiding this comment.
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-level Sentry.init() option?
There was a problem hiding this comment.
I'd prefer keeping it integration only because if Sentry.vueIntegration is filtered out, then trackComponents doesn't do anything.
There was a problem hiding this comment.
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 SDK init() which still allows overriding the vueIntegration options.
Something like vueOptions?
There was a problem hiding this comment.
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.
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.
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 the vueIntegration internally to setup the Vue router. This happens here:
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 SDK init as we cannot call the integration twice.
There was a problem hiding this comment.
So we would still have to add something like a vueOptions key for the Nuxt SDK init as we cannot call the integration twice.
i think that's fine
This was referenced Nov 21, 2024
Lms24
approved these changes
Nov 22, 2024
6 tasks
alexandresoro
pushed a commit
to alexandresoro/ouca-backend
that referenced
this pull request
Dec 8, 2024
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@sentry/node](https://github.com/getsentry/sentry-javascript/tree/master/packages/node) ([source](https://github.com/getsentry/sentry-javascript)) | dependencies | minor | [`8.40.0` -> `8.42.0`](https://renovatebot.com/diffs/npm/@sentry%2fnode/8.40.0/8.42.0) | | [@sentry/react](https://github.com/getsentry/sentry-javascript/tree/master/packages/react) ([source](https://github.com/getsentry/sentry-javascript)) | dependencies | minor | [`8.40.0` -> `8.42.0`](https://renovatebot.com/diffs/npm/@sentry%2freact/8.40.0/8.42.0) | --- ### Release Notes <details> <summary>getsentry/sentry-javascript (@​sentry/node)</summary> ### [`v8.42.0`](https://github.com/getsentry/sentry-javascript/blob/HEAD/CHANGELOG.md#8420) [Compare Source](getsentry/sentry-javascript@8.41.0...8.42.0) ##### Important Changes - **feat(react): React Router v7 support (library) ([#​14513](getsentry/sentry-javascript#14513 This release adds support for [React Router v7 (library mode)](https://reactrouter.com/home#react-router-as-a-library). Check out the docs on how to set up the integration: [Sentry React Router v7 Integration Docs](https://docs.sentry.io/platforms/javascript/guides/react/features/react-router/v7/) ##### Deprecations - **feat: Warn about source-map generation ([#​14533](getsentry/sentry-javascript#14533 In the next major version of the SDK we will change how source maps are generated when the SDK is added to an application. Currently, the implementation varies a lot between different SDKs and can be difficult to understand. Moving forward, our goal is to turn on source maps for every framework, unless we detect that they are explicitly turned off. Additionally, if we end up enabling source maps, we will emit a log message that we did so. With this particular release, we are emitting warnings that source map generation will change in the future and we print instructions on how to prepare for the next major. - **feat(nuxt): Deprecate `tracingOptions` in favor of `vueIntegration` ([#​14530](getsentry/sentry-javascript#14530 Currently it is possible to configure tracing options in two places in the Sentry Nuxt SDK: - In `Sentry.init()` - Inside `tracingOptions` in `Sentry.init()` For tree-shaking purposes and alignment with the Vue SDK, it is now recommended to instead use the newly exported `vueIntegration()` and its `tracingOptions` option to configure tracing options in the Nuxt SDK: ```ts // sentry.client.config.ts import * as Sentry from '@​sentry/nuxt'; Sentry.init({ // ... integrations: [ Sentry.vueIntegration({ tracingOptions: { trackComponents: true, }, }), ], }); ``` ##### Other Changes - feat(browser-utils): Update `web-vitals` to v4.2.4 ([#​14439](getsentry/sentry-javascript#14439)) - feat(nuxt): Expose `vueIntegration` ([#​14526](getsentry/sentry-javascript#14526)) - fix(feedback): Handle css correctly in screenshot mode ([#​14535](getsentry/sentry-javascript#14535)) ### [`v8.41.0`](https://github.com/getsentry/sentry-javascript/blob/HEAD/CHANGELOG.md#8410) [Compare Source](getsentry/sentry-javascript@8.40.0...8.41.0) ##### Important Changes - **meta(nuxt): Require minimum Nuxt v3.7.0 ([#​14473](getsentry/sentry-javascript#14473 We formalized that the Nuxt SDK is at minimum compatible with Nuxt version 3.7.0 and above. Additionally, the SDK requires the implicit `nitropack` dependency to satisfy version `^2.10.0` and `ofetch` to satisfy `^1.4.0`. It is recommended to check your lock-files and manually upgrade these dependencies if they don't match the version ranges. ##### Deprecations We are deprecating a few APIs which will be removed in the next major. The following deprecations will *potentially* affect you: - **feat(core): Update & deprecate `undefined` option handling ([#​14450](getsentry/sentry-javascript#14450 In the next major version we will change how passing `undefined` to `tracesSampleRate` / `tracesSampler` / `enableTracing` will behave. Currently, doing the following: ```ts Sentry.init({ tracesSampleRate: undefined, }); ``` Will result in tracing being *enabled* (although no spans will be generated) because the `tracesSampleRate` key is present in the options object. In the next major version, this behavior will be changed so that passing `undefined` (or rather having a `tracesSampleRate` key) will result in tracing being disabled, the same as not passing the option at all. If you are currently relying on `undefined` being passed, and and thus have tracing enabled, it is recommended to update your config to set e.g. `tracesSampleRate: 0` instead, which will also enable tracing in v9. The same applies to `tracesSampler` and `enableTracing`. - **feat(core): Log warnings when returning `null` in `beforeSendSpan` ([#​14433](getsentry/sentry-javascript#14433 Currently, the `beforeSendSpan` option in `Sentry.init()` allows you to drop individual spans from a trace by returning `null` from the hook. Since this API lends itself to creating "gaps" inside traces, we decided to change how this API will work in the next major version. With the next major version the `beforeSendSpan` API can only be used to mutate spans, but no longer to drop them. With this release the SDK will warn you if you are using this API to drop spans. Instead, it is recommended to configure instrumentation (i.e. integrations) directly to control what spans are created. Additionally, with the next major version, root spans will also be passed to `beforeSendSpan`. - **feat(utils): Deprecate `@sentry/utils` ([#​14431](getsentry/sentry-javascript#14431 With the next major version the `@sentry/utils` package will be merged into the `@sentry/core` package. It is therefore no longer recommended to use the `@sentry/utils` package. - **feat(vue): Deprecate configuring Vue tracing options anywhere else other than through the `vueIntegration`'s `tracingOptions` option ([#​14385](getsentry/sentry-javascript#14385 Currently it is possible to configure tracing options in various places in the Sentry Vue SDK: - In `Sentry.init()` - Inside `tracingOptions` in `Sentry.init()` - In the `vueIntegration()` options - Inside `tracingOptions` in the `vueIntegration()` options Because this is a bit messy and confusing to document, the only recommended way to configure tracing options going forward is through the `tracingOptions` in the `vueIntegration()`. The other means of configuration will be removed in the next major version of the SDK. - **feat: Deprecate `registerEsmLoaderHooks.include` and `registerEsmLoaderHooks.exclude` ([#​14486](getsentry/sentry-javascript#14486 Currently it is possible to define `registerEsmLoaderHooks.include` and `registerEsmLoaderHooks.exclude` options in `Sentry.init()` to only apply ESM loader hooks to a subset of modules. This API served as an escape hatch in case certain modules are incompatible with ESM loader hooks. Since this API was introduced, a way was found to only wrap modules that there exists instrumentation for (meaning a vetted list). To only wrap modules that have instrumentation, it is recommended to instead set `registerEsmLoaderHooks.onlyIncludeInstrumentedModules` to `true`. Note that `onlyIncludeInstrumentedModules: true` will become the default behavior in the next major version and the `registerEsmLoaderHooks` will no longer accept fine-grained options. The following deprecations will *most likely* not affect you unless you are building an SDK yourself: - feat(core): Deprecate `arrayify` ([#​14405](getsentry/sentry-javascript#14405)) - feat(core): Deprecate `flatten` ([#​14454](getsentry/sentry-javascript#14454)) - feat(core): Deprecate `urlEncode` ([#​14406](getsentry/sentry-javascript#14406)) - feat(core): Deprecate `validSeverityLevels` ([#​14407](getsentry/sentry-javascript#14407)) - feat(core/utils): Deprecate `getNumberOfUrlSegments` ([#​14458](getsentry/sentry-javascript#14458)) - feat(utils): Deprecate `memoBuilder`, `BAGGAGE_HEADER_NAME`, and `makeFifoCache` ([#​14434](getsentry/sentry-javascript#14434)) - feat(utils/core): Deprecate `addRequestDataToEvent` and `extractRequestData` ([#​14430](getsentry/sentry-javascript#14430)) ##### Other Changes - feat: Streamline `sentry-trace`, `baggage` and DSC handling ([#​14364](getsentry/sentry-javascript#14364)) - feat(core): Further optimize debug ID parsing ([#​14365](getsentry/sentry-javascript#14365)) - feat(node): Add `openTelemetryInstrumentations` option ([#​14484](getsentry/sentry-javascript#14484)) - feat(nuxt): Add filter for not found source maps (devtools) ([#​14437](getsentry/sentry-javascript#14437)) - feat(nuxt): Only delete public source maps ([#​14438](getsentry/sentry-javascript#14438)) - fix(nextjs): Don't report `NEXT_REDIRECT` from browser ([#​14440](getsentry/sentry-javascript#14440)) - perf(opentelemetry): Bucket spans for cleanup ([#​14154](getsentry/sentry-javascript#14154)) Work in this release was contributed by [@​NEKOYASAN](https://github.com/NEKOYASAN) and [@​fmorett](https://github.com/fmorett). Thank you for your contributions! </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xNDIuNyIsInVwZGF0ZWRJblZlciI6IjM4LjE0Mi43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=--> Reviewed-on: https://git.tristess.app/alexandresoro/ouca/pulls/374 Reviewed-by: Alexandre Soro <[email protected]> Co-authored-by: renovate <[email protected]> Co-committed-by: renovate <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Ref: #14265
Currently there are 4 ways of configuring the
tracingOptions:tracingOptionsin Sentry.init()vueIntegration()optionstracingOptionsin thevueIntegration()optionsBecause that is may to many ways of configuration, we decided that the only way should be inside
tracingOptionsin thevueIntegration()options.