When Flare's JavaScript SDK reports an error, it includes a version identifier. This version ties the error to a specific sourcemap upload so we can show you clean, readable stacktraces instead of minified code.
By default, our Vite and Webpack plugins generate a random UUID for each build. That gets the job done, but when you're staring at an error in Flare, a version like a3f8e2b1-7c4d-4e9f-b6a1-2d5f8c3e7a9b doesn't tell you much.
There's a better option: use your git commit hash as the version identifier. Instead of a random string, you'll see something like e4a7c3f next to every error. Run git log e4a7c3f and you're looking at the exact code that was deployed when things went wrong.
Let's set it up.
Getting the commit hash at build time
Both our Vite and Webpack plugins run during your build process, so you can grab the current commit hash right there in your config file:
import { execSync } from 'child_process';
const commitHash = execSync('git rev-parse --short HEAD').toString().trimEnd();
This gives you a short, 7-character hash like e4a7c3f. If you'd rather use the full 40-character hash, just drop the --short flag.
Vite
Pass the commit hash as the version option in your vite.config.js:
import { defineConfig } from 'vite';
import { execSync } from 'child_process';
import flareSourcemapUploader from '@flareapp/vite';
const commitHash = execSync('git rev-parse --short HEAD').toString().trimEnd();
export default defineConfig({
plugins: [
flareSourcemapUploader({
key: 'YOUR-FLARE-PROJECT-KEY',
version: commitHash,
}),
],
});
Every build now tags its sourcemaps with the commit hash, and the Flare client automatically sends that same hash along with every error report.
Webpack
For Webpack, the option is called versionId:
const { execSync } = require('child_process');
const FlareWebpackPluginSourcemap = require('@flareapp/flare-webpack-plugin-sourcemap');
const commitHash = execSync('git rev-parse --short HEAD').toString().trimEnd();
module.exports = {
plugins: [
new FlareWebpackPluginSourcemap({
key: 'YOUR-FLARE-PROJECT-KEY',
versionId: commitHash,
}),
],
devtool: 'hidden-source-map',
};
If you're using Laravel Mix, the same plugin works in your webpack.mix.js:
const { execSync } = require('child_process');
const FlareWebpackPluginSourcemap = require('@flareapp/flare-webpack-plugin-sourcemap');
const commitHash = execSync('git rev-parse --short HEAD').toString().trimEnd();
mix
.webpackConfig({
plugins: [
new FlareWebpackPluginSourcemap({
key: 'YOUR-FLARE-PROJECT-KEY',
versionId: commitHash,
}),
],
})
.sourceMaps(true, 'hidden-source-map');
Using CI environment variables
Most CI providers already expose the commit hash as an environment variable, so you don't need to shell out to git at all:
const commitHash = process.env.GITHUB_SHA?.slice(0, 7) // GitHub Actions
?? process.env.CI_COMMIT_SHORT_SHA // GitLab CI
?? execSync('git rev-parse --short HEAD').toString().trimEnd();
This uses the CI-provided value when available and falls back to the git command for local builds.
What this looks like in practice
Once deployed, every JavaScript error in Flare shows the commit hash that produced the build. You see an error spiking after a deploy, check the version, and you're one git show away from reading the exact diff that caused it.
No more cross-referencing deploy logs or guessing based on timestamps. Just a direct link from error to commit.
Continue reading
A unified error debug timeline
We've reworked the error debug timeline to show all events in chronological order and added support for HTTP requests, Redis commands, filesystem operations, and caching events.
Ruben
New and improved settings screens
Did someone say Spring Cleaning? We've redesigned the settings pages across Flare to be more consistent, intuitive, and pleasant to use.
Dries
Subscribe to Backtrace, our quarterly Flare newsletter
No spam, just news & product updates