Uh oh!
There was an error while loading. Please reload this page.
meta(changelog): Update changelog for v7.95.0 - #10298
Merged
Merged
Conversation
…ns()` (#10243) The current implementation has two problems: 1. It is weird that you can accidentally mutate the default integrations of another package 2. We sometimes have logic-based default integrations - e.g. adding an integration only if tracing is enabled, or similar. This means that either we have to add some logic in the _upstream_ SDK to ensure this is still added even if downstream SDKs overwrite default integrations, or we need to duplicate the logic in the _downstream_ SDKs. With this new method, we can instead centralize this, and downstream SDKs simply need to call upstream `getDefaultIntegrations(options)`.
The usage of this was not really working well to begin with, and even worse with the new functional integrations. Because if the user adds the integration themselves (e.g. `integrations: [new RewriteFrames()]`), it will not actually get the correct iteratee at all. Overall it is much cleaner anyhow to just fork the integrations properly and use them instead of the default one - then we can rely on the standard behavior of merging integrations etc. We need to do the same for basically all usages of `addOrUpdateIntegration`, as that actually does not work at all anymore with the functional integrations 😬 (and in many instances never really worked properly if users passed in a custom integration themselves). Co-authored-by: Abhijeet Prasad <aprasad@sentry.io>
We should wait for #10243 to merge this, as otherwise we'll get a deprecation/eslint error there.
[Gitflow] Merge master into develop
There have been tries to do this before, but let's see how things stand today...
Deprecate the `Span.parentSpanId` field on the interface and class. This required only a couple of code replacements and a bunch of test adjustments. Also went ahead and changed the integration test event type in the tests I was modifying.
…bute (#10260) Deprecate the `Span.origin` field on the class and the interface. It will be replaced in v8 by the semantic `sentry.op` attribute.
We should think about moving the wasm integration into `@sentry/browser` and removing `@sentry/wasm` all together. What do you think?
By using functional integrations in #10230, we started importing from `@sentry/core` in the WASM integration. However, we didn't register `@sentry/core` as a dependency, making rollup bundle core into the package output. This changed the `build/npm` directory structure, making our entry points in `package.json` invalid. This PR fixes things by simply registering core as a dependency of wasm. If we move WASM to core (which I strongly think we should do), we'll be able to get rid of this again.
… API (#10085) Move `parameterize` function to core, export it to upstream packages via browser and node.
Co-authored-by: Luca Forstner <luca.forstner@sentry.io>
Instead, users should use the new functional styles. Note that we'll probably actually un-deprecate `Replay` in some form in v8, as we'll be keeping the class around there for sure (as there is a lot of logic in there...). But users should not use it, so deprecating this now! While at it, I also deprecated the old `InitSentryForEmber` method in favor of `init()`. It's slightly unfortunate that I missed this, but we probably shouldn't have exposed `ReplayCanvas` as a class anymore at all 😬 maybe we wait before we document this etc. until we merged the functional style. cc @billyvg
…OrUpdateIntegration` (#10263) This updates the last usage of `addOrUpdateIntegration` and deprecates it.
Adds ability to configure all border radiuses on feedback widget Closes#10256
…nt` (#10296) Currently, you can use `Sentry.getClient() !== undefined` to check if Sentry was initialized. In v8, we want to change this so that this _always_ returns a client (possibly a Noop client), so this check will not work anymore there. Instead, we can provide a new util that does this explicitly, where we can control what it checks under the hood.
As per https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseStart, `responseStart` can be 0 if the request is coming straight from the cache. This might lead us to calculate a negative ttfb. To account for these scenarios, use `Math.max` to make sure we always set to 0 in the case of a negative value.
Lms24
reviewed
Jan 23, 2024
Uh oh!
There was an error while loading. Please reload this page.
Contributor
size-limit report 📦
|
mydeaforce-pushed
the
prepare-release/7.95.0
branch
from
January 23, 2024 16:18
7e9f16c to
d98bd74Compare
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
Just 5 more to go to 7.💯 !