Skip to content
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 24 commits into from
Jul 30, 2024
Merged

meta: Update CHANGELOG for 8.21.0 #13100

merged 24 commits into from
Jul 30, 2024

Conversation

Lms24
Copy link
Member

@Lms24 Lms24 commented Jul 30, 2024

No description provided.

AbhiPrasad and others added 24 commits July 24, 2024 09:24
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.
Figured having this written down might prove useful in the future :)
- [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
#13022)

Fixes #12849.

This is a bit tricky because `beforeSendTransaction` can return a
promise, so in order to avoid dealing with this I put the # of spans on
the sdk metadata, and then compare that afterwards.
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`).
#13081)

Fixes #13080

This was basically just wrong - we need stuff from `browser` package
there, so we can't really build the final CDN bundle from the
feedback-internal package.

I moved this over and also adjusted tests to actually test this with
pluggable CDN integrations as well.
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 Lms24 changed the base branch from develop to master July 30, 2024 12:06
@Lms24 Lms24 requested review from a team as code owners July 30, 2024 12:06
@Lms24 Lms24 merged commit f609d05 into master Jul 30, 2024
30 checks passed
@Lms24 Lms24 deleted the prepare-release/8.21.0 branch July 30, 2024 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants