Migrare de la Nuxt 2 la Nuxt 4 în 2026: cost, durată, plan

Dacă produsul tău rulează încă pe Nuxt 2 sau Vue 2, probabil că încă merge. Tocmai asta e problema: nu arde nimic, așa că upgrade-ul tot alunecă mai jos în roadmap. Mai jos e felul în care abordez aceste migrări ca tech lead: riscurile, opțiunile, ce se strică și cum estimez și planific trecerea la Nuxt 4 fără să opresc dezvoltarea de funcționalități noi.

Unde sunt Nuxt 2 și Vue 2 în noiembrie 2026

• Vue 2 a ajuns la final de viață (end of life) pe 31 decembrie 2023. Ultima versiune e 2.7.16.
• Nuxt 2 a ajuns la end of life pe 30 iunie 2024. Ultima versiune e 2.18.1.
• Nuxt 3 a ajuns la end of life pe 31 iulie 2026, după ce data inițială, ianuarie 2026, a fost amânată.
• Nuxt 4 a fost lansat în iulie 2025 și e linia stabilă actuală (4.6 în momentul în care scriu).
• Nuxt 5 nu are încă nicio versiune publicată. Roadmap-ul oficial îl estimează pentru ultimul trimestru din 2026, cu Nitro v3 și h3 v2 la bază.

Concluzia: sari peste Nuxt 3, care deja nu mai e suportat, și mergi direct pe Nuxt 4. Nuxt 4 rămâne suportat până la șase luni după lansarea lui Nuxt 5, iar de la 4.2 poți activa multe dintre schimbările din Nuxt 5 cu future.compatibilityVersion: 5, cum face și acest site.

Ce înseamnă end of life în practică

Securitate. Două vulnerabilități Vue 2 publicate în 2024, CVE-2024-6783 (XSS, severitate medie) și CVE-2024-9506 (ReDoS, severitate scăzută), nu sunt reparate în pachetele publice. Într-un audit SOC 2 sau într-un chestionar de securitate al unui client enterprise, un framework fără suport e o problemă pe care trebuie s-o explici de fiecare dată.

Dependențe. Vuetify 2 a ajuns la end of life în ianuarie 2025. Ultima versiune BootstrapVue a apărut în octombrie 2022, pe Bootstrap 4, iar biblioteca n-a avut niciodată o versiune pentru Vue 3. Pinia 4, lansat în iulie 2026, cere Vue 3, iar în octombrie 2026 repository-urile @nuxtjs/axios și @nuxtjs/auth au fost arhivate.

Recrutare. Developerii care au învățat Vue în ultimii ani au învățat Vue 3, Composition API și Vite, iar un cod pe Vue 2, webpack 4 și Vuex îi atrage mult mai greu.

Cele trei opțiuni

1. Migrare incrementală

Pregătești codul cât e încă pe Nuxt 2, schimbi framework-ul de dedesubt, apoi muți restul pagină cu pagină. E varianta pe care o recomand în majoritatea cazurilor: aplicația rămâne oricând gata de lansare, iar riscul vine în bucăți mici, ușor de verificat.

2. Rescriere de la zero

Pornești un proiect Nuxt 4 nou și reconstruiești tot. Uneltele de programare cu AI fac asta să pară ieftin, dar o rescriere aruncă ani de buguri rezolvate și de cazuri limită pe care nu le-a documentat nimeni, iar aplicația veche stă pe loc până o ajunge din urmă cea nouă. O recomand doar când aplicația e mică, codul chiar nu mai poate fi salvat sau oricum se redesenează majoritatea ecranelor. Dacă rescrii cu unelte AI, treci înainte de lansare prin checklist-ul meu pentru lansarea în producție a unei aplicații vibe-coded.

3. Suport extins plătit

HeroDevs vinde Never-Ending Support (NES) pentru Vue 2, Nuxt 2 și Vuetify 2: pachete drop-in care primesc în continuare patch-uri de securitate, făcute în parteneriat cu echipele Vue și Nuxt și menționate în anunțurile lor de end of life. Ambele CVE-uri de mai sus sunt reparate în NES. Prețul se stabilește după numărul de developeri care fac commit în repository.

E o alegere rezonabilă dacă aplicația va fi retrasă în următorii doi ani, dacă un audit nu poate aștepta finalul migrării sau dacă vrei timp să migrezi cum trebuie. Nu rezolvă însă ecosistemul, recrutarea sau migrarea în sine: plătești ca să stai pe loc, apoi plătești oricum mutarea.

Ce se strică de fapt

Data fetching: de la asyncData la useFetch

O pagină tipică în Nuxt 2:

<script>
export default {
  async asyncData({ params, $axios }) {
    const post = await $axios.$get(`/api/posts/${params.slug}`)
    return { post }
  },
  head() {
    return { title: this.post.title }
  },
}
</script>

Aceeași pagină în Nuxt 4:

<script setup lang="ts">
const route = useRoute()
const { data: post } = await useFetch(() => `/api/posts/${route.params.slug}`)

useSeoMeta({
  title: () => post.value?.title,
})
</script>

În Nuxt 4, data e un shallow ref care pornește ca undefined, nu null, iar apelurile cu aceeași cheie îl împart. useFetch nu înlocuiește direct hook-ul fetch() din Nuxt 2, așa că pe acelea le verific de mână.

De la Vuex la Pinia

Un modul de store în Nuxt 2, store/cart.js:

export const state = () => ({ items: [] })

export const getters = {
  total: state => state.items.reduce((sum, item) => sum + item.price, 0),
}

export const mutations = {
  add(state, item) {
    state.items.push(item)
  },
}

Versiunea Pinia, app/stores/cart.ts:

interface CartItem {
  id: string
  price: number
}

export const useCartStore = defineStore('cart', {
  state: () => ({ items: [] as CartItem[] }),
  getters: {
    total: state => state.items.reduce((sum, item) => sum + item.price, 0),
  },
  actions: {
    add(item: CartItem) {
      this.items.push(item)
    },
  },
})

În componente, this.$store.commit('cart/add', item) devine useCartStore().add(item). Pinia 2 suportă încă Vue 2.7 și poate rula lângă Vuex, așa că deseori încep să mut store-urile înainte de schimbarea framework-ului.

Biblioteci UI, build și module

Biblioteca UI e locul unde estimările o iau razna. Vuetify 3 și versiunile următoare schimbă componentele, props-urile și grid-ul, iar BootstrapVueNext țintește Bootstrap 5. Oricare dintre ele atinge aproape fiecare ecran, așa că o planific ca pe un flux de lucru separat.

Vite e builder-ul implicit. Frecările vin din loaderele webpack custom, din apelurile require() și din citirile directe din process.env, pentru că Nuxt e ESM nativ, iar valorile de runtime trec prin useRuntimeConfig. Caut fiecare modul în directorul de module Nuxt, să văd dacă are versiune pentru Nuxt 4. Nuxt 4 încă recunoaște vechea structură de foldere, dar cum oricum se mută totul, adopt directorul app/ din prima.

Cum estimezi volumul de muncă

Înainte să dau o ofertă, citesc și rulez codul și fac un inventar:

• Pagini și layout-uri, fiecare fiind o unitate de portare și testare.
• Componente, împărțite în cele de prezentare și cele care folosesc filtre, mixin-uri, $on sau this.$store.
• Module Vuex, cu mărimea lor și câte componente le folosesc.
• Module și pluginuri, fiecare marcat „are versiune pentru Nuxt 4”, „are înlocuitor” sau „abandonat”.
• Config webpack custom, serverMiddleware și ciudățenii de SSR, cum ar fi codul care atinge window chiar la import.

Apoi acoperirea cu teste. Testele unitare scrise pentru Vue 2 trebuie adesea migrate și ele. Ce ține cu adevărat o migrare în picioare sunt testele end-to-end pe fluxurile critice: autentificare, checkout, formularele importante. Playwright controlează un browser real și nu-l interesează ce framework a randat pagina, așa că testele scrise pe aplicația Nuxt 2 devin definiția lui „gata” pentru cea pe Nuxt 4. Dacă nu există, scrierea lor e primul pas.

Durate și costuri estimate

Acestea sunt estimări, nu oferte, la tariful meu de 480 €/zi. Migrările pornesc de la 3.000 €, iar cifra reală vine după ce îți citesc codul.

Cele mai mari diferențe vin din biblioteca UI, din modulele abandonate și din lipsa testelor. Durata presupune că echipa ta face review și merge în una-două zile. După analiza codului primești un preț fix sau o estimare pe zile de lucru, așa cum scrie pe pagina de migrări legacy.

Planul pas cu pas

1. Audit și plan. Inventarul, blocajele, înlocuitorii, ordinea lucrului și estimarea, toate în scris.
2. Plasa de siguranță. Teste Playwright pe fluxurile critice ale aplicației actuale, plus monitorizarea erorilor, ca să ai un punct de referință.
3. Pregătirea pe Nuxt 2. Treci pe Nuxt 2.18.1 și Vue 2.7.16, care a preluat din Vue 3 Composition API și <script setup>. Înlocuiește filtrele, scoate event bus-ul și începe să muți modulele Vuex pe Pinia.
4. Izolează biblioteca UI. Împachetează componentele Vuetify 2 sau BootstrapVue în componente de bază proprii, ca înlocuirea de mai târziu să se facă într-un singur folder.
5. Deschide branch-ul de Nuxt 4. defineNuxtConfig, directorul app/, Vite, runtimeConfig și versiunile pentru Nuxt 4 ale modulelor tale. Fă zilnic merge din main în el.
6. Portează paginile rută cu rută. asyncData devine useAsyncData sau useFetch, head() devine useSeoMeta, opțiunile de pagină trec în definePageMeta, iar middleware-ul în defineNuxtRouteMiddleware.
7. Portează restul. Pluginurile, serverMiddleware mutat în rute de server Nitro, store-urile rămase și noua bibliotecă UI în spatele componentelor tale de bază.
8. Verifică. Rulează testele end-to-end, compară fiecare URL, titlu, meta descriere, canonical și intrare din sitemap cu producția și verifică Core Web Vitals. Crawlerele AI citesc același HTML randat pe server; detalii în cum ajungi să fii recomandat de ChatGPT și de căutarea AI.
9. Lansează într-o fereastră stabilită. Urmărește erorile și Search Console în primele zile, cu build-ul vechi pregătit pentru rollback.
10. Curățenie și predare. Scoate shim-urile și codul mort, actualizează README-ul și treci cu echipa prin tot ce s-a schimbat.

Cum livrezi funcționalități în timpul migrării

O migrare care oprește roadmap-ul pentru două luni n-ar trebui aprobată. Uite cum continuă livrarea:

• Cea mai mare parte a riscului ajunge devreme în producție. Pașii 2–4 se lansează pe Nuxt 2, prin release-urile obișnuite.
• Codul nou se scrie pentru Vue 3 din prima zi: <script setup>, Pinia, fără filtre, fără event bus. Se mută pe Nuxt 4 aproape neschimbat.
• Branch-ul ține pasul zilnic cu main, așa că funcționalitățile construite între timp se portează pe parcurs, nu într-un singur merge dureros.
• Pauza e scurtă și planificată: câteva zile în jurul merge-ului final, stabilite din timp.
• Aplicațiile mari se pot muta pe secțiuni, cu Nuxt 4 lângă Nuxt 2 în spatele unui reverse proxy, preluând câte un grup de rute pe rând.

Dacă vrei să mă ocup eu de migrare, asta e serviciul meu de migrări legacy: analiza codului, un plan scris cu preț, apoi upgrade-ul în pași mici, testați. După aceea pot continua prin dezvoltare Nuxt sau, pentru aplicații din spatele unui login, prin dezvoltare Vue.js. Trimite-mi package.json-ul și un rând despre aplicație prin formularul de colaborare și îți răspund în cel mult o zi lucrătoare.

FAQ

Pot migra direct de la Nuxt 2 la Nuxt 4, fără Nuxt 3?

Da, și asta recomand. Nuxt 3 e la end of life din 31 iulie 2026, deci dacă te oprești acolo trebuie să planifici imediat a doua migrare. Configurezi direct un proiect Nuxt 4 și îți portezi codul în el.

Mai merită Nuxt Bridge în 2026?

Rareori. Bridge e încă publicat și aduce în Nuxt 2 multe funcționalități din Nuxt 3, dar rulează tot pe Nuxt 2, care e la end of life. De obicei fac pregătirea direct pe Nuxt 2.18 și Vue 2.7; Bridge e cel mult o treaptă intermediară, niciodată o destinație.

Trebuie să rescriu toate componentele în Composition API?

Nu. Options API funcționează în Vue 3, iar echipa Vue a spus că nu are în plan să renunțe la el. Convertesc componentele la <script setup> când oricum le modific din alte motive, iar pe cele stabile le las în pace.

Aplicația mea e pe Vue 2 simplu, fără Nuxt. Planul se aplică și aici?

În mare parte, da. Vuex, filtrele, event bus-ul, biblioteca UI și trecerea de la webpack-ul din Vue CLI la Vite înseamnă aceeași muncă. Build-ul de migrare al Vue, @vue/compat, rulează cod în stil Vue 2 pe Vue 3 cât timp repari avertismentele unul câte unul. Să adaugi și Nuxt merită doar dacă ai nevoie de randare pe server pentru SEO.

Cât costă o migrare de la Nuxt 2 la Nuxt 4?

Depinde de mărime, de dependențele abandonate și de acoperirea cu teste. La 480 €/zi, aplicațiile mici ajung de obicei la 3.000–5.800 €, cele medii la 7.200–14.400 €, iar cele mari pornesc de la aproximativ 16.800 €. Primești un preț fix sau o estimare pe zile după analiza codului.