@sentry-internal/feedback
Advanced tools
Changelog
8.45.0
handled
option to captureConsoleIntegration
(#14664)HttpClient
events (#14515)captureMessage
with attachStacktrace: true
as synthetic (#14668)captureMessage
with attatchStackTrace: true
as synthetic (#14670)level
in server runtime captureException
(#10587)Work in this release was contributed by @anonrig and @Zih0. Thank you for your contributions!
Changelog
8.43.0
feat(nuxt): Add option autoInjectServerSentry (no default import()) (#14553)
Using the dynamic import()
as the default behavior for initializing the SDK on the server-side did not work for every project.
The default behavior of the SDK has been changed, and you now need to use the --import
flag to initialize Sentry on the server-side to leverage full functionality.
Example with --import
:
node --import ./.output/server/sentry.server.config.mjs .output/server/index.mjs
In case you are not able to use the --import
flag, you can enable auto-injecting Sentry in the nuxt.config.ts
(comes with limitations):
sentry: {
autoInjectServerSentry: 'top-level-import', // or 'experimental_dynamic-import'
},
feat(browser): Adds LaunchDarkly and OpenFeature integrations (#14207)
Adds browser SDK integrations for tracking feature flag evaluations through the LaunchDarkly JS SDK and OpenFeature Web SDK:
import * as Sentry from '@sentry/browser';
Sentry.init({
integrations: [
// Track LaunchDarkly feature flags
Sentry.launchDarklyIntegration(),
// Track OpenFeature feature flags
Sentry.openFeatureIntegration(),
],
});
feat(browser): Add featureFlagsIntegration
for custom tracking of flag evaluations (#14582)
Adds a browser integration to manually track feature flags with an API. Feature flags are attached to subsequent error events:
import * as Sentry from '@sentry/browser';
const featureFlagsIntegrationInstance = Sentry.featureFlagsIntegration();
Sentry.init({
// Initialize the SDK with the feature flag integration
integrations: [featureFlagsIntegrationInstance],
});
// Manually track a feature flag
featureFlagsIntegrationInstance.addFeatureFlag('my-feature', true);
feat(astro): Add Astro 5 support (#14613)
With this release, the Sentry Astro SDK officially supports Astro 5.
feat(nextjs): Deprecate typedef for hideSourceMaps
(#14594)
The functionality of hideSourceMaps
was removed in version 8 but was forgotten to be deprecated and removed.
It will be completely removed in the next major version.
feat(core): Deprecate APIs around RequestSession
s (#14566)
The APIs around RequestSession
s are mostly used internally.
Going forward the SDK will not expose concepts around RequestSession
s.
Instead, functionality around server-side Release Health will be managed in integrations.
browserSessionIntegration
(#14551)raw_security
envelope types (#14562)disableAnrDetectionForCallback
function (#14359)trackIncomingRequestsAsSessions
option to http integration (#14567)autoInjectServerSentry
(no default import()
) (#14553)^1.29.0
(#14590)1.28.0
(#14547)filename
and module
stack frame properties in Node stack parser (#14544)maxSpanWaitDuration
values (#14632)parseSearch
option in TanStack Router instrumentation (#14328)Work in this release was contributed by @lsmurray. Thank you for your contribution!
Changelog
8.42.0
feat(react): React Router v7 support (library) (#14513)
This release adds support for React Router v7 (library mode). Check out the docs on how to set up the integration: Sentry React Router v7 Integration Docs
feat: Warn about source-map generation (#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)
Currently it is possible to configure tracing options in two places in the Sentry Nuxt SDK:
Sentry.init()
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:
// sentry.client.config.ts
import * as Sentry from '@sentry/nuxt';
Sentry.init({
// ...
integrations: [
Sentry.vueIntegration({
tracingOptions: {
trackComponents: true,
},
}),
],
});
Changelog
8.41.0
meta(nuxt): Require minimum Nuxt v3.7.0 (#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.
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)
In the next major version we will change how passing undefined
to tracesSampleRate
/ tracesSampler
/ enableTracing
will behave.
Currently, doing the following:
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)
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)
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)
Currently it is possible to configure tracing options in various places in the Sentry Vue SDK:
Sentry.init()
tracingOptions
in Sentry.init()
vueIntegration()
optionstracingOptions
in the vueIntegration()
optionsBecause 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)
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:
arrayify
(#14405)flatten
(#14454)urlEncode
(#14406)validSeverityLevels
(#14407)getNumberOfUrlSegments
(#14458)memoBuilder
, BAGGAGE_HEADER_NAME
, and makeFifoCache
(#14434)addRequestDataToEvent
and extractRequestData
(#14430)sentry-trace
, baggage
and DSC handling (#14364)openTelemetryInstrumentations
option (#14484)NEXT_REDIRECT
from browser (#14440)Work in this release was contributed by @NEKOYASAN and @fmorett. Thank you for your contributions!