Nuxt SDK

[stephanie-anderson]

Important

This issue is tracking progress on the Nuxt SDK. If you find bugs or problems with the @sentry/nuxt package please open a separate issue. Thank you!

New SDK for https://nuxt.com/

There is an existing discussion: Sentry SDK for Nuxt

Nuxt uses nitro as their server, this means we'll need to have nitro support. It might make sense for us to create an OpenTelemetry instrumentation for nitro. It will also be valuable to add similar instrumentation for the other libraries Nuxt relies on:

• crossws: their websocket wrapper: https://crossws.unjs.io/
• db0: their database wrapper: https://github.com/unjs/db0
• unstorage: their key/value storage wrapper: https://github.com/unjs/unstorage

Alpha

Beta Give feedback

1. Add Nuxt SDK package boilerplate #12572
   Package: nuxt +1
2. Add client (vue) instrumentation
3. sentryNuxtPlugin for error handling
4. Add server (nitro) instrumentation #12795
   +0
5. Add side effect import of sentry config to Nuxt app #12759
   Package: nuxt +1
6. Add E2E tests
7. Add craft entry for Nuxt SDK
8. Nuxt: Add source maps support #13017
   +0
9. Nuxt: Route Parametrization #13067
   +0
10. Nuxt: Connected traces #13097
    +0

Beta

Beta Give feedback

1. Create Nuxt Platfrom in Sentry
2. Nuxt: Source Maps support for server-side #13383
   +0
3. Create Docs for Nuxt #13239
   +0
4. Add icon for Nuxt platformicons#174
   +0
5. [Nuxt] Cannot set release name used by sentry-vite-plugin #13380
   Package: nuxt +1
   
6. feat(nuxt): Add server config to root folder #13583
   Package: nuxt +1
7. Nuxt: Vue component tracking test(nuxt): Add tests for Vue component tracking #13633

Stable Release

Beta Give feedback

1. Nitro Route Parametrization
2. Nuxt Setup Wizard

Nice to have/Stretch Goals

Beta Give feedback

1. Add Nuxt pages router instrumentation
2. Add Nuxt pages router unit tests
3. Add support for Nuxt Layers
4. Add worker runtime support
5. (if needed) Add native Nitro server engine support
6. (if needed) Instrument Nuxt $fetch
7. Instrument useError composable
8. Nuxt (optional): Make it possible to use runtime config in external file #13341
   Package: nuxt +1

[AbhiPrasad]

See #6929

[manniL]

If you need insights from the Nuxt team at any time, please don't hesitate to reach out! 🙏

[cosbgn]

This is such a great news!

It would be ideal that it would work on all envs.
Nuxt works very well on the edge (cloudflare workers, netlify edge, etc), however not all libraries are compatible as there are some restrictions (no eval, no new Function(), etc).

It would be great if sentry/nuxt would work everywhere from day one.

[s1gr1d]

@cosbgn Thanks for the input! Which libraries do you mean with "not all libraries are compatible"?

[cosbgn]

@cosbgn Thanks for the input! Which libraries do you mean with "not all libraries are compatible"?

Hi @s1gr1d, I don't have an extensive list, but for example AJV doesn't work. Workers don't use node, they use their own runtime (workerd) which is limited to web standards (similarly to deno).

I think if you use only sentry/core it should work as it's used by toucan-js which is an unofficial client for cloudflare workers. I think sentry/node won't work by default, but I might be wrong here.

[cosbgn]

This is of course for the backend part of nuxt, i.e. nitro. On the frontend sentry/vue should work perfectly.

[alexcroox]

I use Sentry on my APIs (fullstack Nuxt 3 deployment to Cloudflare pages) with the sentry/browser package on the API side to get around edge restrictions.

The context Sentry devs, for cosbgn's comment, is that Nuxt 3 was built with the "deploy anywhere" ethos, so all the core packages and (new) community modules are designed to be runtime agnostic. That's where https://unjs.io/ was born from.

I initially followed this guide if it helps at all with the PR in general https://www.lichter.io/articles/nuxt3-sentry-recipe (written by a core Nuxt 3 dev)

[lforst]

While we may not support worker (WinterCG) runtimes from the start we will look into it eventually. We are planning to release the SDK iteratively and in stages. Prioritization of worker runtime support depends of course a bit on the demand. I added an item to the list to track. Technically we have all the building blocks available.

[cosbgn]

I don't have any specific data, but from my understanding a big percent of nuxt apps are deployed on the edge (vercel-edge, workers, netlify edge, etc) as you get better performance for lower costs, and Nuxt pretty much "guarantees" that it will work on the edge, so it's an obvious solution.

I understand if you decide not to prioritize it, I just wanted to let you know that it would be great to have it from day one. It might be as simple as using sentry/core rather than sentry/node (I don't know, just an example).

Anyways, thanks for the first party package, love sentry and I would love to be able to add it to Nuxt easily!

[gloompiq]

Great initiative!

Could we also make sure that errors before the hydration are also handled?

[s1gr1d]

We want to monitor as many as possible. The first release of the SDK will cover monitoring the majority of errors and we will definitely improve it over time

[nkmnz]

Hi @s1gr1d , thank you for the hard work so far :-) I have two questions with regard to the server instrumentation:

1. I'd like to better understand the reasoning behind putting the server instrumentation into a file in the public folder. Nuxt hosts all files in public on the root of the project, e.g. ~/public/logo.svg would be available in the browser at http://localhost:3000/logo.svg (or at the respective production URL). Is there any need to publish the instrumentation file via a web server if it's only used when running the start or preview scripts from package.json? I guess the idiosyncratic way would be to put it into a scripts folder.

2. Also, did you consider the alternative to initialize Sentry inside of the server-plugin as @manniL did here? We could pass all options from the nuxt config file, which could include functions as well?

[mydea]

Hey, thank you for your feedback!

@s1gr1d is out today, she can answer in more detail on Monday!
Generally speaking, the main challenge we have is that we need to run Sentry in an --import flag, in order for ESM instrumentation to work. This means that you cannot just inject some script in v8 of the SDK into the server and have everything instrumented correctly, but you need to configure this at app boot time - which means you need to have the file to reference/import at the time that the nuxt server is started.

I am not saying that the public/ folder is necessarily the ideal solution, but this is the main constraint we have to work around - if we find a better way to do this, we'd definitely be happy to! We are still investigating different approaches here :)

[AlejandroAkbal]

Would be great if, within the sentry.client.config.ts file, we would able to use the runtime config:

https://nuxt.com/docs/api/composables/use-runtime-config

Example from other module: https://formkit.com/getting-started/installation#using-environment-variables-in-formkitconfigts

The code below

import * as Sentry from '@sentry/nuxt'

Sentry.init({
enabled: process.env.NUXT_PUBLIC_SENTRY_ENABLED,
})

Would then become:

import * as Sentry from '@sentry/nuxt'

export default defineSentryConfig(() => {

const config = useRuntimeConfig()

Sentry.init({
enabled: config.public.sentry.enabled,
})
})

Yeah, because right now there is no way to use Nuxt public config right?

[s1gr1d]

@nkmnz It is in the public folder right now, because the file needs to be added to the build output as it is (to reference it in the node option input). But I agree that this is not 100% ideal and this will be changed probably.

About your 2. point: Do you mean creating a server-plugin yourself? The SDK already adds a server-plugin with the necessary hooks. But the initialization takes place in the instrument file and is loaded with the node option import. It has to be added with import to initialize sentry at the very start. This is needed for the otel instrumentation to work correctly in ESM (which Nuxt is). Without initializing the SDK at the very start, only the basic http instrumentation will work.

[Anton-Plagemann]

@nkmnz It is in the public folder right now, because the file needs to be added to the build output as it is (to reference it in the node option input). But I agree that this is not 100% ideal and this will be changed probably.

About your 2. point: Do you mean creating a server-plugin yourself? The SDK already adds a server-plugin with the necessary hooks. But the initialization takes place in the instrument file and is loaded with the node option import. It has to be added with import to initialize sentry at the very start. This is needed for the otel instrumentation to work correctly in ESM (which Nuxt is). Without initializing the SDK at the very start, only the basic http instrumentation will work.

Hi @s1gr1d,

can't we use late initiliazation to solve this?
When I understand the article correctly that would mean we can invoke Sentry.init at a later point, even within a server plugin removing the need for the file inside the public folder directory.

[s1gr1d]

Yes, something like this could work. I am just trying different approaches.

[smeubank]

@s1gr1d some feedback from someone testing out the Nuxt SDK. Some of this feedback i think holds true regarding the file requirements for config of most of our JS SDKs, especially the meta frameworks.

running in dev, i notice that Nuxt has a dev tool bar, slightly (un)related but i wonder if Sentry could interact there? Like you could get more info about the error in browser in dev mode?

Tried it out today. Looking great! Here are just a few things I found that could use improvement IMO:

1. having the instrument.server.mjs file in the public folder is kind of weird. Feels more natural in the root. Maybe can copy to public folder on build? Changing the commands for the build is also weird. I'm sure Daniel Roe or Alex Lichter could point you towards a better solution.

2. Would be nice if you could do all the config in the nuxt.config.ts file instead of spread out across 3 different files

3. I trigger an error in a server API endpoint and didn't see it reported in Sentry (https://nuxt.com/docs/guide/directory-structure/server)

4. Would be cool if you could detect the app running in dev vs running in prod and automatically set the environment in sentry

5. Didn't see an error with the fatal option set to true reported to sentry( throw createError({ fatal: true, message: "etc..." }) https://nuxt.com/docs/api/utils/create-error

Hope it helps!

[samulefevre]

I tested it for server, i use startSpan but nothing sent to "Performance".

[lforst]

@samulefevre thanks for trying out the SDK. Would you mind opening a new issue with reproduction steps? Thank you!

[AnthonyRuelle]

Hello,

Thank you for your work!

I'm encountering two significant issues while integrating Sentry into my Nuxt.js project:

1 - Sourcemap Upload Fails on Staging:

Local Build: When building the project locally, the sourcemap is successfully uploaded to Sentry. (
Only when the sentry.client.config.ts file is successfully created)
Staging Environment: On my staging environment (a test environment similar to production), the sourcemap upload fails with the following warning:

caused by: [60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: unable to get local issuer certificate)
error: API request failed

This may be due to server configuration, I will investigate

2 - Environment Variables Not Accessible:
I'm unable to access environment variables in both sentry.client.config.ts and instrument.server.mjs.
I've tried various approaches, but variables remain undefined.
Is there a known solution for this, or is it currently not feasible to access environment variables in these specific files?

3 - Attempted Solution with Nuxt Plugin:

I attempted to create a custom Nuxt plugin to cleanly manage the Sentry configuration, but in this case, the sourcemap upload doesn’t even trigger as the file seems to be unrecognized.

Thank you in advance for your feedback :)

[lforst]

@AnthonyRuelle I transferred your comment into a separate issue because otherwise this issue is gonna get messy af