Nuxt v4.0.1 to v4.0.2 regression
I've recently upgraded from Nuxt v4.0.0 to v4.1.2, but was surprised to find out that running typecheck (nuxt prepare && vue-tsc --build --noEmit) on the new version fails with 400+!! errors, where previously on Nuxt v4.0.0 I had 0 errors. Most of the errors reported are related to using $router.back() , idk why this is reported, the back functionality still works. Also some other errors reported are related to helper functions found in the utils directory, again these continue to work just fine. What changed in 4.1.2? Is this a known issue? Why would it work perfectly in 4.0.0 and not 4.1.2? Going a bit further down the rabbit-hole, it seems the regression happens between v4.0.1 & v4.0.2. btw, i just downgraded nuxt version by version without touching any other packages. (my vue-tsc is v2.2.12 if that's important) Thanks!
5 Replies
Hi @Eugen Schneider. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Short answer: yes—there were TypeScript-related changes between 4.0.1 → 4.0.2 and further in 4.1.x that can surface many more type errors during type checking, even if your app still runs fine.
What changed that could affect vue-tsc results:
- Nuxt tightened/adjusted typings and module resolution around 4.0.2 (e.g. constraining global defineAppConfig, alias tweaks), which can expose previously unreported type issues in your code or dependencies. [v4.0.2]
- Nuxt 4 introduces TypeScript configuration splitting (separate tsconfigs for app/server/node/shared) and supports project references. If you opt in to project references or your tooling starts picking them up, type checking becomes stricter and more context-aware, which can reveal errors that 4.0.0 didn’t flag. [TS config splitting; Migration steps]
- 4.0.3 also included improvements to include tsconfig references during Nuxt’s typeCheck, which may change what vue-tsc sees. [v4.0.3]
- By default, Nuxt does not type-check during dev/build; enabling type checking is done via vue-tsc or nuxt typecheck. If your script changed to use project references (-b/--build), it can amplify reported errors. [TypeScript guide]
Known issues fixed in 4.1.x (not directly your $router.back case, but relevant to “typecheck started failing after upgrade”):
- An emits typing regression in 4.1.0 was fixed shortly after (affecting defineEmits inference when auto-importing components). If you saw new template typing errors around events, upgrading past that fix should help. [Issue 33142; v4.1.2]
- Nuxt 4.1.2 also included various internal type and build fixes that could affect what gets checked. [v4.1.2]
What you can do:
- If you haven’t, try Nuxt’s built-in checker: npx nuxt typecheck. It respects Nuxt’s setup and recent tsconfig references improvements. [TypeScript guide; v4.0.3]
- If you opt into project references, update your scripts as recommended (vue-tsc -b --noEmit) and ensure your root tsconfig uses references to .nuxt/tsconfig.*.json. This aligns vue-tsc with Nuxt’s split configs and can reduce spurious errors. [Migration steps]
- Check whether your helper utils and router usage are being type-checked in the correct context (app vs server vs node). Mis-scoped files can now surface errors with the split configs. [TS config splitting]
Limitations: the knowledge sources don’t mention a specific regression about $router.back() types between 4.0.1 and 4.0.2. The spike in errors you see is plausibly due to the stricter/project-referenced type-checking paths introduced and refined in 4.0.2–4.1.x rather than a runtime regression. If you can share a minimal repro, similar issues have been quickly triaged/fixed in recent patches. [v4.1.2; v4.0.3]
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@218666150949552128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai > Nuxt tightened/adjusted typings and module resolution around 4.0.2 (e.g. constraining global defineAppConfig, alias tweaks), which can expose previously unreported type issues in your code or dependencies. [v4.0.2],
can i get the commit hash for this?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Here are the specific references from the 4.0.2 release that tightened typings/module resolution:
- Constrain global defineAppConfig type: merged via PR #32760. The PR itself doesn’t show a single commit hash in the sources you provided, but it’s listed in the 4.0.2 changelog as “Constrain global defineAppConfig type.” [v4.0.2; defineAppConfig type]
- Add trailing slash to some dir aliases (alias tweaks): merged via PR #32755, referenced in the 4.0.2 changelog as “kit,nuxt,schema: Add trailing slash to some dir aliases.” [v4.0.2]
I’m sorry, but the knowledge sources you shared do not include the exact commit hashes for these changes beyond the PR links and the changelog entry. If you open those PRs on GitHub, you can view the merge commit hash in the “Commits” tab or the merge details. [v4.0.2; defineAppConfig type]
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@218666150949552128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.