Nitro handlers, templates, and Nuxt Doctor

Recognize a handler’s route#

In a standard Nuxt server layout, server/api/users.get.ts and users.post.ts both describe /api/users with different methods. A [id].delete.ts handler maps a dynamic segment plus its method; the method suffix is not part of the public URL.

export default defineEventHandler(() => ({ status: 'ok' }))

This fragment belongs in an installed Nuxt/Nitro project, for example server/api/health.get.ts. Follow supported useFetch('/api/health') references and inspect the handler gutter before testing it in the running application.

Generate familiar source shapes#

Use Nuxt/Nitro live templates for pages, components, composables, plugins, API handlers, and fetch calls. Review paths and exported names after expansion. A template does not install a module or prepare generated framework types.

Inspect Doctor findings#

Nuxt Doctor resolves Nuxt and DevTools versions from installed packages or supported npm/pnpm/Yarn/Bun lockfiles. Lifecycle and security-version findings are reported separately. A package manager detected from a newly added lockfile should be checked against the repository’s intended manager.

Doctor’s copyable upgrade command is a proposal, not an automatic dependency migration. Review it against the framework’s current release guidance and your project’s tests before running it. Error codes in run/debug consoles can link to their dedicated Nuxt documentation.

Debug a mismatch#

If the IDE and running app report different versions, inspect working directory, installed modules, lockfile, script, and generated types. Changing the editor’s selected profile cannot reconcile a stale node_modules tree by itself.

Nuxt-specific key/value completion helps edit .nuxtrc without treating it as TypeScript. Select the image to view it at full size.