-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
ref(nextjs): Merge master into Next.js #3362
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
Conversation
Clarified how the browser SDK is integrated with the other SDKs
…in (#3320) Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.3 to 6.5.4. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](indutny/elliptic@v6.5.3...v6.5.4) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.3 to 6.5.4. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](indutny/elliptic@v6.5.3...v6.5.4) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Update gatsby-node.js * remove additional vercel fallbacks
* misc: 6.2.3 changelog * add whitespace I'm embarrassing myself
* ref: Add fast-path to fetchImpl * fix: Cleanup after fetch impl detection
* fix: Add SentryRequestType to RateLimitingCategory mapping * Update remaining tests
…#3347) * ref(ember): Fix tests to be forward compatible with component changes One of the frameworks provided components, link-to, had a change to it's internal name. It's not really relevant to the test, so normalizing the description should work across the version changes.
* ref(ember): Silence deprecation warnings in beta We can deal with deprecations once they hit mainline, this should hopefully silence deprecations in the scenarios so we can see failures more easily and not spit out too many logs
…tion.prototype.query (#3353)
Try to use the best of performance.timeOrigin or performance.timing.navigationStart as long as they are near the current time reported by Date.now. The intention is to mitigate transactions that are reported with a huge time skew, particularly from Firefox. This is trying to address the inconsistencies between browsers by always trying to use timeOrigin first, as long as its consistent with the current time, otherwise, use the navigationStart if its consistent with the current time, eventually fallback to date if all else fails. We also remember what source is used for the time origin, so we can tag events and analyze later. Co-authored-by: Rodolfo Carvalho <[email protected]> Co-authored-by: Alberto Leal <[email protected]>
size-limit report
|
Ugh, could you maybe rebase this PR please? 😅 |
Closing this in favor of #3366 that has one more commit.
Rebasing the PR is not what we want here. This PR is merging commits from Note that rebasing the |
Good luck merging that branch to master after this PR :P |
When it will be ready we should squash all changes and present a clean PR into master. That's why I'm trying to make sure we don't have to solve conflicts later nor merge unrelated changes (like #3367). |
Merge master into Next.js