With Sentry, you can tag an issue with the environment that it occurred in, such as production or staging, and then filter, search, and set up notifications based on that environment. All right, Vite already has some of this environment information set up for us already, so let's see now how to pass it on from Vite to Sentry. init. mode.
This environment variable is a special environment variable provided by Vite out of the box. During development, when running npm run dev, this variable is set to development. But when we build the site, Vite sets the mode to production. Cool.
So, let's trigger an error in both environments and see what that looks like in Sentry. First, we'll do development mode. I'll run npm run dev. Then, in the application, I'll hit the send email button to trigger the error.
Now, if we go over to the Sentry dashboard, we can see our issue listed. Let's click into it to see more. If I scroll down to the tags section, sure enough, There's an environment tag that has the value of development. Now, let's build our application for production and trigger the error again.
I'll stop the dev server, run npm run build, and then npm run serve. Finally, I'll trigger the error again. Now, if we head over to the Sentry dashboard, you should see the issue that was triggered in the last lesson, now triggered again. Notice the updated timestamp.
If it doesn't update right away for you, just wait a few seconds and refresh the page. You may be wondering why a new issue wasn't created like just a moment ago for the development environment. Well, the reason is because Sentry's default environment is production. Thus, this is just another occurrence of the same issue from the last lesson.
Alright, when we click on this issue, we do see that it is in fact tagged with the production environment. Cool. The tags on the individual issues are nice, but the best part about this is that if we go back to the issues page, now we've got this filter at the top that lets us narrow down the issues we want to see based on those environments. Finally, Veet's mode environment variable isn't limited to just production and development.
Depending on the environment we're building for, We can also specify a custom mode when running npm run build using the mode flag. This pairs perfectly with Sentry environments. With Sentry, you can tag an issue with the environment that it occurred in, such as production or staging, and then filter, search, and set up notifications based on that environment. All right, Vite already has some of this environment information set up for us already, so let's see now how to pass it on from Vite to Sentry.
init. mode. This environment variable is a special environment variable provided by Vite out of the box. During development, when running npm run dev, this variable is set to development.
But when we build the site, Vite sets the mode to production. Cool. So, let's trigger an error in both environments and see what that looks like in Sentry. First, we'll do development mode.
I'll run npm run dev. Then, in the application, I'll hit the send email button to trigger the error. Now, if we go over to the Sentry dashboard, we can see our issue listed. Let's click into it to see more.
If I scroll down to the tags section, sure enough, There's an environment tag that has the value of development. Now, let's build our application for production and trigger the error again. I'll stop the dev server, run npm run build, and then npm run serve. Finally, I'll trigger the error again.
Now, if we head over to the Sentry dashboard, you should see the issue that was triggered in the last lesson, now triggered again. Notice the updated timestamp. If it doesn't update right away for you, just wait a few seconds and refresh the page. You may be wondering why a new issue wasn't created like just a moment ago for the development environment.
Well, the reason is because Sentry's default environment is production. Thus, this is just another occurrence of the same issue from the last lesson. Alright, when we click on this issue, we do see that it is in fact tagged with the production environment. Cool.
The tags on the individual issues are nice, but the best part about this is that if we go back to the issues page, now we've got this filter at the top that lets us narrow down the issues we want to see based on those environments. Finally, Veet's mode environment variable isn't limited to just production and development. Depending on the environment we're building for, We can also specify a custom mode when running npm run build using the mode flag. This pairs perfectly with Sentry environments.