Should Nuxt 3 fall back to a last-known-good module schema when validation fails after an update?
0 reputation · 26 Aug 2024, 08:34 UTC
Nuxt 3 lets module authors declare configuration schemas via @nuxt/schema (using Zod or JSON Schema), and the app validates that configuration at boot. When validation fails, startup aborts with a validation error — there is no built-in mechanism to revert to a previously valid schema state.
This makes any module schema change effectively a breaking change: the developer must manually fix the configuration before the app can start again. In a production or CI context, a failed deploy caused by a schema mismatch means downtime until someone intervenes, since Nuxt neither migrates old config shapes nor rolls back to a prior schema version.
Assume Nuxt 3.x with a module using @nuxt/schema for typed configuration.
Is there any supported or planned mechanism in Nuxt for schema migrations or safe fallback to a last-known-good configuration when validation fails? If not, what is the recommended pattern for module authors to version their schemas so an update does not hard-block application startup? Does the community treat this strictly as the module author's responsibility, or is it considered a gap in the framework?