Nuxt DevTools Observatory: the observability panels I wished Nuxt DevTools had

Victor Neves — Wed, 28 Oct 2026 15:47:38 +0000

Nuxt DevTools is great. But at some point, while debugging real apps, I kept running into the same questions it couldn't answer:

Which useFetch calls are actually in the critical path of this page?
Where does this inject() get its value from, and why is it undefined here?
Is that composable leaking a watcher or an interval after the component unmounts?
Why does this component re-render 40 times?
What exactly happened between the route change and the page being ready?

So I built Nuxt DevTools Observatory, a module that adds deeper runtime observability on top of the official DevTools. It complements Nuxt DevTools, it doesn't replace it.

👉 Repo: victorlmneves/nuxt-devtools-observatory
👉 Docs: nuxt-devtools-observatory.vercel.app

Getting started

pnpm add nuxt-devtools-observatory

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['nuxt-devtools-observatory'],
  devtools: { enabled: true },
})

Open Nuxt DevTools and the new tabs show up. That's it. Everything is enabled by default in development, and you can turn individual features off via the observatory key in nuxt.config.ts.

What you get

1. useFetch Dashboard

A central view of every useFetch / useAsyncData call: key, URL, status, origin (SSR or CSR), payload size, duration, and a waterfall timeline. Server-side timing is captured by a Nitro plugin and sent to the client over the HMR WebSocket, so you see SSR fetches too.

2. provide/inject Graph

An interactive graph of your injection topology. Nodes are colour-coded (provides, injects, both, missing provider), and you get:

inline value inspection for each provided key
scope badges (global, layout, component)
shadow detection when a child re-provides a key an ancestor already provides
immediate flagging of any inject() that resolves to undefined
jump-to-editor from the detail panel

3. Composable Tracker

This is the one I use most. It tracks your useXxx() composables live: returned ref, computed and reactive values, a change history, and global (shared) state detection by comparing object identity across instances.

Most importantly, it flags leaks: any watcher or interval still active after onUnmounted fires.

You can also edit a writable ref inline and the new value is applied to the live ref in the running app, which is handy for reproducing edge cases without touching code.

4. Render Heatmap

A component tree colour-coded by render frequency and duration, with a per-component render timeline, trigger keys and a route filter. You can set thresholds (heatmapThresholdCount, heatmapThresholdTime) to highlight the offenders, and export/import snapshots as JSON.

5. Pinia Tracker

For each Pinia store: state snapshots, an action/mutation timeline with before/after diffs, dependency edges (which components and composables touch the store) and hydration attribution (nuxt-payload, persistedstate or runtime).

6. Transition Tracker

A live timeline of every <Transition> lifecycle event with phase, duration, parent component and cancellation state. It's surprisingly useful for finding transitions that never finish because of missing CSS classes, or ones cancelled by rapid toggling.

7. Trace Viewer

Per-route traces that capture everything that happened after a navigation, in order: component mounts, real render durations, fetch timing, composable setup, server phases and transitions. You can inspect them as a Flamegraph or a Waterfall, and compare render behaviour across traces to spot regressions.

It helps answer things like "is this page slow because of setup(), or because of DOM patching?" and "which useFetch is blocking the critical path?"

How it works (the interesting part)

All instrumentation happens at build time through Vite transforms that wrap calls at the AST/module level before compilation:

useFetch / useAsyncData are wrapped with a thin shim that records timing and payload.
provide() / inject() are wrapped with versions that carry file and line metadata. At runtime, a findProvider() walks the instance.parent chain to find who provided each key.
Any useX() call matching Vue's naming convention is wrapped with a tracking shim that watches for new effects and intervals created during setup.
<Transition> is trickier. The Vue 3 template compiler emits direct named imports (import { Transition as _Transition } from "vue"), which bypass app.component() entirely. So the module serves a virtual proxy module for vue that overrides the Transition export with an instrumented wrapper.

One detail I'm happy with: the transition wrapper deliberately does not wrap onEnter / onLeave. Vue inspects their .length to choose between CSS and JS timing modes, and wrapping them would change that length and silently alter behaviour.

Zero cost in production

Instrumentation is dev-only. When import.meta.dev is false, the transforms are skipped entirely, so there's no runtime overhead in production.

Things to know

Performance in dev: since it wraps fetches, composables and lifecycle hooks, very large apps may see a slower DevTools UI or higher memory usage. Disable what you don't need, and use the max* options (maxFetchEntries, maxComposableEntries, etc.) to cap memory.
SSR vs SPA: instrumentServer defaults to true for SSR apps and false for SPAs, to avoid double registration from the transform running on both builds.
Opt out per call: add /* @devtools-ignore */ before any call you don't want instrumented.

/* @devtools-ignore */
const { data } = useFetch('/api/sensitive')

Known gap: the Render Heatmap route filter can't hide persistent components (layouts), since they appear on every route by definition.

Try it

The repo includes a playground with intentionally broken scenarios: leaky composables, a missing provider, a heavy list that re-renders constantly, and transitions that are broken or cancelled. Clone it and you can see every panel light up without writing any code:

pnpm install
pnpm dev

Feedback welcome

The project is MIT-licensed and still young. If you try it, I'd love to hear which panels are useful, what's missing, and where it gets in your way. Issues, discussions and PRs are all welcome.

⭐ github.com/victorlmneves/nuxt-devtools-observatory

Vue.js + Vite - How to dynamically inline SVG's without 3rd party libraries

Victor Neves — Sun, 13 Mar 2022 15:03:20 +0000

Recently on a project that I'm working on with Vue 3 + Vite and using a Server Driven UI approach while building a basic link component that can include icons I started researching for tools that could help me, as we are using SVGs and in order to better manipulate them (e.g change the color on hover), we need to inline them.

The problem

When working with Server Driven UI you don't exactly the data that you will gonna render and in this particular case, we don't know which icon will be added, so it's "not possible" to import the asset on the component as there are several icons that can be rendered. Well, it's possible but you would have to import all of them on the component and create a computed method to check the icon name received on the response in order to grab the icon from the list of available options. As you can imagine having several icons is not the best approach for a maintainable system besides you will import all icons even not using them.

Problem There a 3rd party libraries that can help to dynamically inline SVGs. I have worked with one of them (svg-sprite) on a previous project. It's nice as in terms of syntax you have something like this when you need to inline an SVG:

<svg width="32" height="32">
    <use :xlink:href="checkedIcon"></use>
</svg>

Basically, you pass the name of the icon that you want to render. Pretty easy right? Well, after setup everything up, yes but you will spend time for that, and every time that a new icon is added to the system, you will have to add the icon to a JSON file. As you can see it's almost the same thing as I have described where you have to import every icon on the component, of course in this case you inline an SVG wherever you need as this will gonna be available overall components.

Solution

After seeing this tip import shaderString from './shader.glsl?raw' on Vite docs I started testing some implementations to see if I could achieve the same result but dynamically. When appending the parameter "?raw" you basically have access to the content of the file, so when used with SVG files you have the code inside and not the file itself.

Code example

<script setup lang="ts">
import { computed } from 'vue'

interface Props {
  url: string;
  text: string;
  hasIcon?: boolean;
  icon?: string;
  ariaLabel?: string;
  externalLink?: boolean;
  target?: string;
}

const linkData = defineProps<Props>()
const isExternalLink = computed(() => linkData.externalLink)
const displayIcon = computed(() => linkData.hasIcon)
const icon = computed(() => linkData.icon)
const target = computed(() => linkData.target || '_blank')
const ariaText = computed(() => linkData.ariaLabel ? linkData.ariaLabel : linkData.text)
const getSvgIcons = await fetch(`assets/images/icons/${icon.value}.svg?raw`)
const svgIcon = computed(() => {
  try {
    return getSvgIcons.data.value
  } catch (error: any) {
    throw new Error(error)
  }
})
</script>

<template>
  <a
    v-if="isExternalLink"
    :target="target"
    :href="url"
    :aria-label="ariaText"
    rel="noopener noreferrer"
    class="base-link"
  >
    <span class="base-link__item">
      <i
        v-if="displayIcon"
        class="base-link__icon"
        v-html="svgIcon"
      ></i>
      {{ text }}
    </span>
  </a>
  <router-link
    v-else
    :to="url"
    :aria-label="ariaText"
    class="base-link"
  >
    <span class="base-link__item">
      <i
        v-if="displayIcon"
        class="base-link__icon"
        v-html="svgIcon"
      ></i>
      {{ text }}
    </span>
  </router-link>
</template>

DEV Community: Victor Neves