-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Simplify/reorganize Micro Frontend Suport #9215
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
Changes from 11 commits
3b53334
55de202
09ca16b
9573613
b7a817e
bc35c2c
dbff8f2
5bd1a2f
da2820e
4511e1e
8954cd2
1144e30
cfe4745
bdbc5fd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -14,18 +14,29 @@ keywords: | |||||
| If your frontend includes JavaScript bundles from multiple sources with | ||||||
| different release cycles, you may want to identify these or route events to specific projects. This is especially useful if you've set up [module federation](https://module-federation.github.io/) or a similar frontend architecture. | ||||||
|
|
||||||
| ## Identifying the source of errors | ||||||
| Below we offer two approaches. Please note that `Sentry.init()` must be called only once, doing otherwise will result in undefined behavior. | ||||||
|
|
||||||
| To identify the source of an error, you must inject metadata that helps identify | ||||||
| which bundles were responsible for the error. You can do this with any of the | ||||||
| Sentry bundler plugins by enabling the `_experiments.moduleMetadata` option. | ||||||
| ## Automatically Route Errors to Different Projects Depending on Module | ||||||
|
|
||||||
| `ModuleMetadata` and `makeMultiplexedTransport` can be used together to automatically route | ||||||
| events to different Sentry projects based on the module where the error | ||||||
| occurred. | ||||||
|
|
||||||
| <Note> | ||||||
| <ul> | ||||||
| <li> | ||||||
| Requires version `2.5.0` or higher of `@sentry/webpack-plugin` or version | ||||||
| `2.7.0` or higher of `@sentry/rollup-plugin`, `@sentry/vite-plugin` or `@sentry/esbuild-plugin`. | ||||||
| </li> | ||||||
| <li> | ||||||
| Requires SDK version `7.59.0` or higher. | ||||||
| </li> | ||||||
| </ul> | ||||||
| </Note> | ||||||
|
|
||||||
| `moduleMetadata` can be any serializable data or alternatively a function that | ||||||
| returns serializable data. If you supply a function, it will be passed an object | ||||||
| containing the `org`, `project`, and `release` strings. | ||||||
| First, to identify the source of an error, you must inject metadata that helps identify | ||||||
| which bundles were responsible for the error. You can do this with any of the | ||||||
| Sentry bundler plugins by enabling the `_experiments.moduleMetadata` option. | ||||||
|
||||||
|
|
||||||
| ```javascript | ||||||
| // webpack.config.js | ||||||
|
|
@@ -37,61 +48,63 @@ module.exports = { | |||||
| sentryWebpackPlugin({ | ||||||
| /* Other plugin config */ | ||||||
| _experiments: { | ||||||
| moduleMetadata: ({ org, project, release }) => { | ||||||
| return { team: "frontend", release }; | ||||||
| }, | ||||||
| moduleMetadata: ({ release }) => ({ dsn: "__MODULE_DSN__", release }), | ||||||
| }, | ||||||
| }), | ||||||
| ], | ||||||
| }; | ||||||
| ``` | ||||||
|
|
||||||
| ### `ModuleMetadata` Integration | ||||||
|
|
||||||
| Requires SDK version `7.59.0` or higher. | ||||||
|
|
||||||
| Once metadata has been injected into modules, the `moduleMetadataIntegration` | ||||||
| can be used to look up that metadata and attach it to stack frames with | ||||||
| matching file names. This metadata is then available in other integrations or in | ||||||
| the `beforeSend` callback as the `module_metadata` property on each | ||||||
| `StackFrame`. This can be used to identify which bundles may be responsible | ||||||
| for an error and used to tag or route events. | ||||||
| matching file names. This metadata is then available in the `beforeSend` callback | ||||||
| as the `module_metadata` property on each `StackFrame`. This can be used to identify | ||||||
| which bundles may be responsible for an error. Once the destination is determined, you can | ||||||
| store it as a list of DSN-release pairs in `event.extra[MULTIPLEXED_TRANSPORT_EXTRA_KEY]` | ||||||
| for the multiplexed transport to reference for routing. | ||||||
|
|
||||||
| In practice, here is what your Sentry initialization should look like: | ||||||
|
|
||||||
| ```javascript | ||||||
| import * as Sentry from "@sentry/browser"; | ||||||
| import { init, makeFetchTransport, moduleMetadataIntegration, makeSimpleMultiplexedTransport, MULTIPLEXED_TRANSPORT_EXTRA_KEY } from "@sentry/browser"; | ||||||
|
||||||
| import { init, makeFetchTransport, moduleMetadataIntegration, makeSimpleMultiplexedTransport, MULTIPLEXED_TRANSPORT_EXTRA_KEY } from "@sentry/browser"; | |
| import { init, makeFetchTransport, moduleMetadataIntegration, MULTIPLEXED_TRANSPORT_EXTRA_KEY } from "@sentry/browser"; |
Once we added the makeSimpleMultiplexedTransport API we can revisit this but for now I'd leave it away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good.
Reverting sample code to original including this change (as it hasn't been tested)
- [Automatic] remove redundant if (routeTo.length) { check for empty array (done in matcher)
@lforst We should simplify the API sooner than later though. I feel like current sample code looks convoluted to the point of customers thinking "surely there must be an easier/more elegant way to do it, let me see what those other blog posts that showed up in search say"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, right now it is unfortunately not a priority for us and I'd like to avoid us losing focus but maybe I can sneak your PR in somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very good to mention. I wonder if we should highlight this even stronger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done