-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
meta: Update CHANGELOG for 8.21.0 #13100
Merged
Merged
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
As per https://vitest.dev/config/#globals > By default, vitest does not provide global APIs for explicitness I think we should follow vitest defaults here and explicitly import in the APIs that we need. This refactors our Svelte SDK tests to do so. ref #11084 This change also removes `environment: 'jsdom'` from the vite config in favour of explicitly adding jsdom environment via the `@vitest-environment` pragma to the specific test file that needs it. This should means that our server tests are not polluted with jsdom globals, and that future writers have to explicitly opt-in to the behaviour. I was also getting some ts errors in the tests, so addressed those as well.
Reverts #12980 We no longer need to pin to Node 22.4 now that Node 22.5.1 has been released. https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V22.md#22.5.1
…Hub Action (#13037) Extending the "how to" with information about the new GitHub action.
As per https://vitest.dev/config/#globals > By default, vitest does not provide global APIs for explicitness I think we should follow vitest defaults here and explicitly import in the APIs that we need. This refactors our Replay SDK tests to do so. This change also removes `environment: 'jsdom'` from the vite config in favour of explicitly adding jsdom environment via the `@vitest-environment` pragma to the specific test file that needs it. This should means that our non-browser tests are not polluted with jsdom globals, and that future writers have to explicitly opt-in to the behaviour.
[Gitflow] Merge master into develop
…2983) Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
Changes wording to lead people sharing a reproduction example.
Adding the Vue BrowserTracing instrumentation to get parametrized routes.
- [x] If you've added code that should be tested, please add tests. - [x] Ensure your code lints and the test suite passes (`yarn lint`) & (`yarn test`).fe This addition adds an intuitive way to resize screenshots in the user feedback widget. The draggable area is bound by the canvas box (so it won't overflow) and is only draggable when cropped (when confirm/cancel buttons present) https://github.com/user-attachments/assets/7ddff991-a791-4d41-a2ad-b278e1ab4950
When using the SDK without tracing, the span processor is not required - we should reflect this in our validation logic. While at it, I also improved the warning for not using the SentrySampler.
Before reviewing this patch, I recommend reading through a writeup I did: #13007 This PR adds `withSentry`, a method that wraps your cloudflare worker handler to add Sentry instrumentation. The writeup above explains why we need to do this over just a regular `Sentry.init` call. The implementation of `withSentry` is fairly straightforward, wrapping the fetch handler in the cloudflare worker with: 1. `withIsolationScope` to isolate it from other concurrent requests 2. helpers to update scope with relevant contexts/request 3. `continueTrace` to continue distributed tracing 4. `startSpan` to track spans Usage looks something like so: ```ts import * as Sentry from '@sentry/cloudflare'; export default withSentry( (env) => ({ dsn: env.SENTRY_DSN, tracesSampleRate: 1.0, }), { async fetch(request, env, ctx) { return new Response('Hello World!'); }, } satisfies ExportedHandler<Env>, ); ``` Next step here is to add more robust e2e tests, and then release an initial version!
Explicitly add a changelog entry for cloudflare so it's ready to go whenever the team decides to do a release.
Get `@sentry/cloudflare` ready for release.
Before submitting a pull request, please take a look at our [Contributing](https://github.com/getsentry/sentry-javascript/blob/master/CONTRIBUTING.md) guidelines and verify: - [ ] If you've added code that should be tested, please add tests. - [ ] Ensure your code lints and the test suite passes (`yarn lint`) & (`yarn test`).
Also changes the `findDefaultSdkInitFile` function as the backend-related file is located and named differently than the client config file (`sentry.client.config.ts` and `public/instrument.server.mjs`). closes #13097
Lms24
force-pushed
the
prepare-release/8.21.0
branch
from
July 30, 2024 11:30
2a4eff1
to
67b978d
Compare
mydea
approved these changes
Jul 30, 2024
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.
No description provided.