In this lesson, let's get those stack traces cleaned up. But first, we need to know a thing or two about releases in Sentry. In Sentry, a release is a version of your code that is deployed to an environment. When you give Sentry information about your releases, you can do a number of different things.
You can determine issues and regressions introduced in a new release. You could predict which commit caused an issue. and who is likely responsible. You could resolve issues by including the issue number in your commit message.
You could receive email notifications when your code gets deployed. You can also monitor release health, which we'll dive deeper into during a later lesson. And lastly, you can apply source maps to minify JavaScript to view original untransformed source code. Okay, all of those definitely seem quite helpful.
But, how do we come up with a release name? Well, a release can be named really anything you'd like, but it's common to name them using the same strategy you use for versioning your project. json file, along with the package name. Okay, cool.
That makes sense. So, how do we now pass this information on to Sentry and How do we provide Sentry with our source maps, so we don't have to make end users download source maps in production, costing them both bandwidth and performance? Well, if we were using Vue CLI, we could use the official Sentry Webpack plugin. Since we're using Vite though, we'll need to use the community-supported Vite port of the plugin.
Vite plugin Sentry. It's basically the same thing as the Vue CLI version, but just for Veet. First, we'll need to install it. I'll do that by typing npm install veet-plugin-sentry.
Then, we'll import it into the Veet config file and register it as a Veet plugin, passing it a config variable that we'll define momentarily. All right, let me just paste in the config now as it's quite a chunk of code. The first thing we'll need to start filling this in is the sentry auth token. local.
sentry__auth__token. js file, since it's sensitive information that really shouldn't be stored in a Git repo. env files are available throughout the source code, but, as far as I can make it work, aren't yet available in the config file. Alright, to generate an auth token in the Sentry dashboard, you can navigate to settings, developer settings, and then click new internal integration.
Let's call it Sentry course integration. And we can skip over all these other details here. And once we get to permissions, we'll want to choose admin access for the project, admin access for the release, and lastly, admin access for the organization. And then I'll hit save changes.
Now. At the bottom of the screen, you can see the token used to authorize this integration. local file. Great.
That takes care of the auth token. The next configuration values we need for the Veet Sentry plugin is the organization and the project. Now, if you take a look at the URL in the Sentry dashboard, you can find both of those values that we need. The organization comes right after organizations.
And the project comes right after projects. Cool. I'll grab those and copy and paste them. Next is the release name.
json. The last important piece of this config is the source maps option. It tells Sentry where the source maps are located. Now that Sentry needs the source maps in production, we need to instruct Vite to produce the source maps during the build for production.
However, we just don't want to link them from the actual application. sourceMaps option set to hidden. We'll also need to inform the Sentry JavaScript SDK running in the browser of the release name. Since in Vite, we can't directly access the process variable in our source code.
we'll need to inject that using Vite's define option. Pay special attention to the quotes inside of the backticks here, as they are necessary because of the way that Vite injects this variable into the source code. js. You can ignore the red squiggly lines here in VS code.
It's just not aware of how Vite is injecting that variable. Cool. json. Now, we can run the application using npm run build.
When the build process is done, we can see some feedback about the source maps uploaded to Sentry. Also, in the Sentry dashboard, we can now visit the releases page. 1 is listed there. Awesome.
If we click into the release, and find the source maps on the right hand side. We can check out the source maps that were uploaded. All right, now let's run MPO run serve to preview our production application and then trigger the error again. Now in the Sentry dashboard, we see a new issue being reported.
It's not grouped with the previous issue because the stack trace has changed due to the source maps now being included. Setting up source maps only happens once for a project though, and everything from here on out will include the source maps. Clicking into the issue, we can now see a much more helpful stack trace that's a lot easier to follow and shows us more of what we're looking for. Also, notice the release tag above.
It contains our release number. Nice! In this lesson, let's get those stack traces cleaned up. But first, we need to know a thing or two about releases in Sentry.
In Sentry, a release is a version of your code that is deployed to an environment. When you give Sentry information about your releases, you can do a number of different things. You can determine issues and regressions introduced in a new release. You could predict which commit caused an issue.
and who is likely responsible. You could resolve issues by including the issue number in your commit message. You could receive email notifications when your code gets deployed. You can also monitor release health, which we'll dive deeper into during a later lesson.
And lastly, you can apply source maps to minify JavaScript to view original untransformed source code. Okay, all of those definitely seem quite helpful. But, how do we come up with a release name? Well, a release can be named really anything you'd like, but it's common to name them using the same strategy you use for versioning your project.
json file, along with the package name. Okay, cool. That makes sense. So, how do we now pass this information on to Sentry and How do we provide Sentry with our source maps, so we don't have to make end users download source maps in production, costing them both bandwidth and performance?
Well, if we were using Vue CLI, we could use the official Sentry Webpack plugin. Since we're using Vite though, we'll need to use the community-supported Vite port of the plugin. Vite plugin Sentry. It's basically the same thing as the Vue CLI version, but just for Veet.
First, we'll need to install it. I'll do that by typing npm install veet-plugin-sentry. Then, we'll import it into the Veet config file and register it as a Veet plugin, passing it a config variable that we'll define momentarily. All right, let me just paste in the config now as it's quite a chunk of code.
The first thing we'll need to start filling this in is the sentry auth token. local. sentry__auth__token. js file, since it's sensitive information that really shouldn't be stored in a Git repo.
env files are available throughout the source code, but, as far as I can make it work, aren't yet available in the config file. Alright, to generate an auth token in the Sentry dashboard, you can navigate to settings, developer settings, and then click new internal integration. Let's call it Sentry course integration. And we can skip over all these other details here.
And once we get to permissions, we'll want to choose admin access for the project, admin access for the release, and lastly, admin access for the organization. And then I'll hit save changes. Now. At the bottom of the screen, you can see the token used to authorize this integration.
local file. Great. That takes care of the auth token. The next configuration values we need for the Veet Sentry plugin is the organization and the project.
Now, if you take a look at the URL in the Sentry dashboard, you can find both of those values that we need. The organization comes right after organizations. And the project comes right after projects. Cool.
I'll grab those and copy and paste them. Next is the release name. json. The last important piece of this config is the source maps option.
It tells Sentry where the source maps are located. Now that Sentry needs the source maps in production, we need to instruct Vite to produce the source maps during the build for production. However, we just don't want to link them from the actual application. sourceMaps option set to hidden.
We'll also need to inform the Sentry JavaScript SDK running in the browser of the release name. Since in Vite, we can't directly access the process variable in our source code. we'll need to inject that using Vite's define option. Pay special attention to the quotes inside of the backticks here, as they are necessary because of the way that Vite injects this variable into the source code.
js. You can ignore the red squiggly lines here in VS code. It's just not aware of how Vite is injecting that variable. Cool.
json. Now, we can run the application using npm run build. When the build process is done, we can see some feedback about the source maps uploaded to Sentry. Also, in the Sentry dashboard, we can now visit the releases page.
1 is listed there. Awesome. If we click into the release, and find the source maps on the right hand side. We can check out the source maps that were uploaded.
All right, now let's run MPO run serve to preview our production application and then trigger the error again. Now in the Sentry dashboard, we see a new issue being reported. It's not grouped with the previous issue because the stack trace has changed due to the source maps now being included. Setting up source maps only happens once for a project though, and everything from here on out will include the source maps.
Clicking into the issue, we can now see a much more helpful stack trace that's a lot easier to follow and shows us more of what we're looking for. Also, notice the release tag above. It contains our release number. Nice!