Configuring Sentry Source Maps Release Versions for Qiankun Micro‑Frontend Projects
This article explains how to configure Sentry source map uploads and release versioning for both standard and Qiankun micro‑frontend projects, presenting two methods (webpack plugin and Sentry CLI) and offering fixed and custom release strategies to keep error reporting and source maps in sync.
When using Sentry for error monitoring, uploading the generated Source Maps is essential for accurate stack traces. Sentry provides two ways to upload these files: the @sentry/webpack-plugin and the sentry-cli command.
Webpack plugin method – install the plugin and add it to your webpack configuration:
// Install the plugin
yarn add @sentry/webpack-plugin --dev
npm install @sentry/webpack-plugin --save-dev// Use the plugin
const SentryCliPlugin = require('@sentry/webpack-plugin');
const config = {
plugins: [
new SentryCliPlugin({
include: path.resolve(__dirname, './build/static/js'),
ignore: ['node_modules', 'webpack.config.js'],
release: 'xxx',
project: 'xxx',
urlPrefix: 'xxxx',
url: 'xxx',
// ...other options
}),
],
};Sentry CLI method – run the CLI command at upload time:
npx sentry-cli releases files <release_name> upload-sourcemaps xxx --url-prefix=xxxBoth methods require that the release value used when uploading Source Maps matches the release passed to Sentry.init at runtime; otherwise the uploaded maps will not be applied.
For simple SPA projects this consistency is easy to achieve by using the same hard‑coded release in both places. However, in a micro‑frontend architecture such as Qiankun, the main application and child applications may have different release identifiers, making synchronization more complex.
The article proposes two solutions to keep the release identifiers aligned:
Solution 1: Fixed Release
Hard‑code a release (e.g., the Sentry Project ID) in both the main app’s Sentry.init and the child app’s Source Map upload configuration. This guarantees matching releases but lacks flexibility for version‑based debugging.
Solution 2: Custom Release
Generate a dynamic release identifier for each child app and expose it to the main app via an inline script in the child’s index.html. The main app can then read window["<custom‑release>"] when intercepting error reports and rewrite the release parameter accordingly.
Example of injecting a custom release with html-webpack-plugin:
const HtmlWebpackPlugin = require('html-webpack-plugin');
const config = {
plugins: [
new HtmlWebpackPlugin({
templateContent: `
<html>
<body>
<h1>Hello World</h1>
<script type="text/javascript">
window["by-aicc-release"] = 'xxxxx';
</script>
</body>
</html>
`,
}),
],
};When the main application intercepts an error and determines it belongs to the by-aicc sub‑application, it can retrieve the release via window["by-aicc-release"] and set the same value in the error reporting request, ensuring the uploaded Source Maps are correctly applied.
In summary, the fixed‑release approach is straightforward but not recommended for large projects, while the custom‑release strategy provides a more robust solution for real‑world micro‑frontend deployments.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Rare Earth Juejin Tech Community
Juejin, a tech community that helps developers grow.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.