meta(changelog): Update changelog for 8.20.0 #13036
Merged
Conversation
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
…12952) Allows to pass this through to the underlying `expressErrorHandler`. See #12715 (reply in thread)
With the new issues UI (beta), our previous way of skipping issue templates for internally created issues doesn't work anymore. So we add a new template that essentially mimics a blank issue.
[Gitflow] Merge master into develop
As mentioned in here: #12912 (comment) there is no way today to exclude/include esm modules when preloading today. This PR adds the option to pass `registerEsmLoaderHooks` as option to `preloadOpenTelemetry`, which allows to exclude/include packages there as well. Users can then write their own custom `preload` script and configure this there, if wanted. ## Naming I chose to use the same option naming here than for `init`, although the semantics are a bit different - here we can't actually disable the wrapping (because that's the only reason to even call this). We can also use a different name if we want, but I thought this would maybe be easier to understand that this is the same thing 🤔
Adding E2E test app with `@nuxt/test-utils` based on the [Nuxt docs](https://nuxt.com/docs/getting-started/testing#testing-in-a-browser).
Ensure that TWP works with fetch, but we do not emit a span. Otherwise, if a user does not use our tracing functionality but adds their own fetch instrumentation, they get spans twice. The benefit we have with fetch is that fetch is instrumented via diagnostics channel, which means that this can be instrumented multiple times. So if we instrument it, on the plus side this does not interfere with a user instrumenting it again themselves if they want. However, with the previous implementation our integration would always emit spans. If a user is using our own sampler, this is "OK" because it will sample it out. But if a user does not use our sampler, the spans we emit there get sent unintentionally. With this change, we ensure to ignore requests if tracing is disabled. In order to make TWP work, we instead manually inject the propagator headers into the fetch request in this scenario. Part of #12984 Fixes #12969
Add `BrowserTracing` when `tracesSampleRate` is set.
- Adds a new nest root module that can be used to setup the Nest SDK as a replacement for the existing setup (with a function). Instead of calling `setupNestErrorHandler` in the main.ts file, users can now add `SentryModule.forRoot()` (feedback about the name is definitely welcome) as an import in their main app module. This approach is much more native to nest than what we used so far. This root module is introduced in the setup.ts file. - This root module is exported with a submodule export `@sentry/nestjs/setup`, because the SDK now depends on nestjs directly and without this the nest instrumentation does not work anymore, since nest gets imported before Sentry.init gets called, which disables the otel nest instrumentation. - Judging from the e2e tests it seems that this new approach also resolves some issues the previous implementation had, specifically [this issue](#12351) seems to be resolved. The e2e test that was in place, just documented the current (wrong) behavior. So I updated the test to reflect the new (correct) behavior. - I updated all the test applications to use the new approach but kept a copy of the nestjs-basic and nestjs-distributed-tracing with the old setup (now named node-nestjs-basic and node-nestjs-distributed-tracing respectively) so we can still verify that the old setup (which a lot of people use) still keeps working going forward. - Updated/New tests in this PR: - Sends unexpected exception to Sentry if thrown in Submodule - Does not send expected exception to Sentry if thrown in Submodule and caught by a global exception filter - Does not send expected exception to Sentry if thrown in Submodule and caught by a local exception filter - Sends expected exception to Sentry if thrown from submodule registered before Sentry - To accomodate the new tests I added several submodules in the nestjs-with-submodules test-application. These are overall similarly but have important distinctions: - example-module-local-filter: Submodule with a local filter registered using `@UseFilters` on the controller. - example-module-global-filter: Submodule with a global filter registered using APP_FILTER in the submodule definition. - example-module-global-filter-wrong-registration-order: Also has a global filter set with APP_FILTER, but is registered in the root module as first submodule, even before the SentryIntegration is initialized. This case does not work properly in the new setup (Sentry should be set first), so this module is used for tests documenting this behavior. - Also set "moduleResolution": "Node16" in the nestjs-basic sample app to ensure our submodule-export workaround works in both, default and sub-path-export-compatible TS configs as was suggested [here](#12948 (comment)).
…uestError` hook (#13020)
Adds `triggerAriaLabel` to configure the aria label of the trigger
button.
The aria label is set to the first value that's non-empty:
1. `triggerAriaLabel`
2. `triggerLabel`
3. TRIGGER_LABEL ("Report a Bug")
Closes #12505
`[email protected]` supports regular expressions for `include` and `exclude`. Is there a risk here that users might not have the latest version of `import-in-the-middle` in their dependencies?
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 Solid SDK tests to do so. ref #11084 This change also removes `environment: 'jsdom'` from the vite config as it seems nothing needs this for solid. This should means that our tests are not polluted with jsdom globals, and that future writers have to explicitly opt-in to the behaviour.
Specify how Nuxt is set up on the server-side. Nuxt v3+ runs with ESM. --------- Co-authored-by: Andrei <[email protected]>
size-limit report 📦
|
andreiborza
approved these changes
Jul 24, 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.