BackVolver al blog

Next.js 15

Next.js 15 introduce soporte para React 19, mejoras en el almacenamiento en caché, una versión estable de Turbopack en desarrollo, nuevas APIs y más.

Next.js 15 es oficialmente estable y está listo para producción. Esta versión se basa en las actualizaciones de RC1 y RC2. Nos hemos enfocado fuertemente en la estabilidad mientras agregamos algunas actualizaciones emocionantes que creemos que te encantarán. Prueba Next.js 15 hoy:

terminal
# Usa la nueva CLI de actualización automatizada
npx @next/codemod@canary upgrade latest
 
# ...o actualiza manualmente
npm install next@latest react@rc react-dom@rc

También estamos emocionados de compartir más sobre lo que viene en Next.js Conf este jueves 24 de octubre.

Esto es lo nuevo en Next.js 15:

Actualizaciones fluidas con la CLI @next/codemod

Incluimos codemods (transformaciones de código automatizadas) con cada lanzamiento importante de Next.js para ayudar a automatizar la actualización de cambios importantes.

Para hacer las actualizaciones aún más fluidas, hemos lanzado una CLI de codemod mejorada:

Terminal
npx @next/codemod@canary upgrade latest

Esta herramienta te ayuda a actualizar tu base de código a las últimas versiones estables o preliminares. La CLI actualizará tus dependencias, mostrará los codemods disponibles y te guiará para aplicarlos.

La etiqueta canary usa la última versión del codemod mientras que latest especifica la versión de Next.js. Recomendamos usar la versión canary del codemod incluso si estás actualizando a la última versión de Next.js, ya que planeamos seguir agregando mejoras a la herramienta basadas en tus comentarios.

Aprende más sobre la CLI de codemod de Next.js.

APIs de solicitud asíncrona (Cambio importante)

En el Renderizado del lado del servidor (SSR) tradicional, el servidor espera una solicitud antes de renderizar cualquier contenido. Sin embargo, no todos los componentes dependen de datos específicos de la solicitud, por lo que no es necesario esperar la solicitud para renderizarlos. Idealmente, el servidor prepararía tanto como sea posible antes de que llegue una solicitud. Para habilitar esto y sentar las bases para futuras optimizaciones, necesitamos saber cuándo esperar la solicitud.

Por lo tanto, estamos haciendo que las APIs que dependen de datos específicos de la solicitud—como headers, cookies, params y searchParams—sean asíncronas.

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
 
  // ...
}

Este es un cambio importante y afecta las siguientes APIs:

  • cookies
  • headers
  • draftMode
  • params en layout.js, page.js, route.js, default.js, generateMetadata y generateViewport
  • searchParams en page.js

Para una migración más fácil, estas APIs pueden accederse temporalmente de forma síncrona, pero mostrarán advertencias en desarrollo y producción hasta la próxima versión importante. Hay disponible un codemod para automatizar la migración:

Terminal
npx @next/codemod@canary next-async-request-api .

Para casos donde el codemod no pueda migrar completamente tu código, por favor lee la guía de actualización. También hemos proporcionado un ejemplo de cómo migrar una aplicación de Next.js a las nuevas APIs.

Semántica de caché

El App Router de Next.js se lanzó con valores predeterminados de almacenamiento en caché opinados. Estos fueron diseñados para proporcionar la opción más performante por defecto con la capacidad de optar por no usarlos cuando sea necesario.

Basándonos en tus comentarios, reevaluamos nuestras heurísticas de caché y cómo interactuarían con proyectos como Partial Prerendering (PPR) y con bibliotecas de terceros que usan fetch.

Con Next.js 15, estamos cambiando el valor predeterminado de caché para los manejadores de ruta GET y el Client Router Cache de almacenado en caché por defecto a no almacenado por defecto. Si deseas mantener el comportamiento anterior, puedes optar por seguir usando el almacenamiento en caché.

Seguiremos mejorando el almacenamiento en caché en Next.js en los próximos meses y compartiremos más detalles pronto.

Los manejadores de ruta GET ya no se almacenan en caché por defecto

En Next.js 14, los manejadores de ruta que usaban el método HTTP GET se almacenaban en caché por defecto a menos que usaran una función dinámica u opción de configuración dinámica. En Next.js 15, las funciones GET no se almacenan en caché por defecto.

Aún puedes optar por el almacenamiento en caché usando una opción de configuración de ruta estática como export dynamic = 'force-static'.

Los manejadores de ruta especiales como sitemap.ts, opengraph-image.tsx y icon.tsx, y otros archivos de metadatos siguen siendo estáticos por defecto a menos que usen funciones dinámicas u opciones de configuración dinámica.

El Client Router Cache ya no almacena componentes de página por defecto

En Next.js 14.2.0, introdujimos una bandera experimental staleTimes para permitir la configuración personalizada del Router Cache.

En Next.js 15, esta bandera sigue siendo accesible, pero estamos cambiando el comportamiento predeterminado para tener un staleTime de 0 para segmentos de página. Esto significa que mientras navegas por tu aplicación, el cliente siempre reflejará los datos más recientes del componente de página que se active como parte de la navegación. Sin embargo, hay comportamientos importantes que permanecen sin cambios:

  • Los datos de diseño compartido no se volverán a obtener del servidor para seguir soportando renderizado parcial.
  • La navegación hacia atrás/adelante seguirá restaurándose desde la caché para garantizar que el navegador pueda restaurar la posición de desplazamiento.
  • loading.js seguirá almacenado en caché durante 5 minutos (o el valor de la configuración staleTimes.static).

Puedes optar por el comportamiento anterior del Client Router Cache configurando lo siguiente:

next.config.ts
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
 
export default nextConfig;

React 19

Como parte del lanzamiento de Next.js 15, hemos decidido alinearnos con el próximo lanzamiento de React 19.

En la versión 15, el App Router usa React 19 RC, y también hemos introducido compatibilidad con versiones anteriores para React 18 con el Pages Router basado en comentarios de la comunidad. Si estás usando el Pages Router, esto te permite actualizar a React 19 cuando estés listo.

Aunque React 19 todavía está en fase RC, nuestras extensas pruebas en aplicaciones del mundo real y nuestro trabajo cercano con el equipo de React nos han dado confianza en su estabilidad. Los cambios importantes principales han sido bien probados y no afectarán a los usuarios existentes del App Router. Por lo tanto, hemos decidido lanzar Next.js 15 como estable ahora, para que tus proyectos estén completamente preparados para React 19 GA.

Para garantizar que la transición sea lo más fluida posible, hemos proporcionado codemods y herramientas automatizadas para ayudar a facilitar el proceso de migración.

Lee la guía de actualización de Next.js 15, la guía de actualización de React 19 y mira la conferencia principal de React Conf para aprender más.

Pages Router en React 18

Next.js 15 mantiene la compatibilidad con versiones anteriores para el Pages Router con React 18, permitiendo a los usuarios seguir usando React 18 mientras se benefician de las mejoras en Next.js 15.

Desde el primer Release Candidate (RC1), hemos cambiado nuestro enfoque para incluir soporte para React 18 basado en comentarios de la comunidad. Esta flexibilidad te permite adoptar Next.js 15 mientras usas el Pages Router con React 18, dándote más control sobre tu ruta de actualización.

Nota: Si bien es posible ejecutar el Pages Router en React 18 y el App Router en React 19 en la misma aplicación, no recomendamos esta configuración. Hacerlo podría resultar en comportamientos impredecibles e inconsistencias en los tipos, ya que las APIs subyacentes y la lógica de renderizado entre las dos versiones pueden no alinearse completamente.

React Compiler (Experimental)

El React Compiler es un nuevo compilador experimental creado por el equipo de React en Meta. El compilador entiende tu código a un nivel profundo a través de su comprensión de la semántica de JavaScript puro y las Reglas de React, lo que le permite agregar optimizaciones automáticas a tu código. El compilador reduce la cantidad de memorización manual que los desarrolladores tienen que hacer a través de APIs como useMemo y useCallback - haciendo el código más simple, fácil de mantener y menos propenso a errores.

Con Next.js 15, hemos agregado soporte para el React Compiler. Aprende más sobre el React Compiler y las opciones de configuración disponibles en Next.js.

Nota: El React Compiler actualmente solo está disponible como un plugin de Babel, lo que resultará en tiempos de desarrollo y construcción más lentos.

Mejoras en los errores de hidratación (Hydration error improvements)

Next.js 14.1 introdujo mejoras en los mensajes de error y los errores de hidratación. Next.js 15 continúa construyendo sobre esas mejoras añadiendo una vista mejorada para los errores de hidratación. Ahora los errores de hidratación muestran el código fuente del error con sugerencias sobre cómo solucionar el problema.

Por ejemplo, este era un mensaje de error de hidratación anterior en Next.js 14.1:

Mensaje de error de hidratación en Next.js 14.1

Next.js 15 ha mejorado esto a:

Mensaje de error de hidratación mejorado en Next.js 15

Turbopack Dev

Nos complace anunciar que next dev --turbo ahora es estable y listo para acelerar su experiencia de desarrollo. Lo hemos estado usando para iterar en vercel.com, nextjs.org, v0, y todas nuestras otras aplicaciones con excelentes resultados.

Por ejemplo, con vercel.com, una aplicación grande de Next.js, hemos visto:

  • Hasta un 76.7% más rápido en el inicio del servidor local.
  • Hasta un 96.3% más rápido en actualizaciones de código con Fast Refresh.
  • Hasta un 45.8% más rápido en la compilación inicial de rutas sin caché (Turbopack aún no tiene caché en disco).

Puede aprender más sobre Turbopack Dev en nuestro nuevo artículo del blog.

Indicador de ruta estática (Static Route Indicator)

Next.js ahora muestra un Indicador de Ruta Estática durante el desarrollo para ayudarle a identificar qué rutas son estáticas o dinámicas. Esta señal visual facilita la optimización del rendimiento al entender cómo se renderizan sus páginas.

También puede usar la salida de next build para ver la estrategia de renderizado de todas las rutas.

Esta actualización es parte de nuestros esfuerzos continuos para mejorar la observabilidad en Next.js, facilitando a los desarrolladores monitorear, depurar y optimizar sus aplicaciones. También estamos trabajando en herramientas de desarrollo dedicadas, con más detalles próximamente.

Aprenda más sobre el Indicador de Ruta Estática, que puede ser desactivado.

Ejecutando código después de una respuesta con unstable_after (Experimental)

Al procesar una solicitud de usuario, el servidor normalmente realiza tareas directamente relacionadas con el cálculo de la respuesta. Sin embargo, es posible que necesite realizar tareas como registro, análisis y sincronización con otros sistemas externos.

Dado que estas tareas no están directamente relacionadas con la respuesta, el usuario no debería tener que esperar a que se completen. Diferir el trabajo después de responder al usuario plantea un desafío porque las funciones serverless detienen el cálculo inmediatamente después de cerrar la respuesta.

after() es una nueva API experimental que resuelve este problema permitiéndole programar trabajo para ser procesado después de que la respuesta haya terminado de transmitirse, permitiendo que las tareas secundarias se ejecuten sin bloquear la respuesta principal.

Para usarla, agregue experimental.after a next.config.js:

next.config.ts
const nextConfig = {
  experimental: {
    after: true,
  },
};
 
export default nextConfig;

Luego, importe la función en Componentes de Servidor, Acciones de Servidor, Manejadores de Ruta o Middleware.

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';
 
export default function Layout({ children }) {
  // Tarea secundaria
  after(() => {
    log();
  });
 
  // Tarea principal
  return <>{children}</>;
}

Aprenda más sobre unstable_after.

instrumentation.js (Estable)

El archivo instrumentation, con la API register(), permite a los usuarios conectarse al ciclo de vida del servidor de Next.js para monitorear el rendimiento, rastrear el origen de errores e integrarse profundamente con bibliotecas de observabilidad como OpenTelemetry.

Esta característica ahora es estable y la opción de configuración experimental.instrumentationHook puede ser eliminada.

Además, hemos colaborado con Sentry en el diseño de un nuevo hook onRequestError que puede ser usado para:

  • Capturar contexto importante sobre todos los errores lanzados en el servidor, incluyendo:
    • Router: Pages Router o App Router
    • Contexto del servidor: Componente de Servidor, Acción de Servidor, Manejador de Ruta o Middleware
  • Reportar los errores a su proveedor de observabilidad favorito.
export async function onRequestError(err, request, context) {
  await fetch('https://...', {
    method: 'POST',
    body: JSON.stringify({ message: err.message, request, context }),
    headers: { 'Content-Type': 'application/json' },
  });
}
 
export async function register() {
  // inicialice el SDK de su proveedor de observabilidad favorito
}

Aprenda más sobre la función onRequestError.

Componente <Form>

El nuevo componente <Form> extiende el elemento HTML <form> con prefetching, navegación del lado del cliente (client-side navigation), y mejora progresiva.

Es útil para formularios que navegan a una nueva página, como un formulario de búsqueda que lleva a una página de resultados.

app/page.jsx
import Form from 'next/form';
 
export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

El componente <Form> incluye:

  • Prefetching: Cuando el formulario está en vista, el layout y la UI de loading son precargados, haciendo la navegación más rápida.
  • Navegación del lado del cliente (Client-side Navigation): Al enviar, los layouts compartidos y el estado del lado del cliente se preservan.
  • Mejora progresiva (Progressive Enhancement): Si JavaScript no se ha cargado aún, el formulario sigue funcionando mediante navegación de página completa.

Anteriormente, lograr estas características requería mucho código repetitivo manual. Por ejemplo:

Ejemplo

// Nota: Este es un ejemplo abreviado para fines de demostración.
// No se recomienda para usar en código de producción.
 
'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // si el destino del formulario es una URL, precárguela
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // obtenga todos los campos del formulario y active un `router.push` con los datos codificados en URL
    const formData = new FormData(event.currentTarget)
    const data = new URLSearchParams()
 
    for (const [name, value] of formData) {
      data.append(name, value as string)
    }
 
    router.push(`${action}?${data.toString()}`)
  }
 
  if (typeof action === 'string') {
    return <form onSubmit={onSubmit} {...props} />
  }
 
  return <form {...props} />
}

Aprenda más sobre el Componente <Form>.

Soporte para next.config.ts

Next.js ahora soporta el tipo de archivo TypeScript next.config.ts y proporciona un tipo NextConfig para autocompletado y opciones con seguridad de tipos:

next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* opciones de configuración aquí */
};
 
export default nextConfig;

Aprenda más sobre el soporte de TypeScript en Next.js.

Mejoras para autoalojamiento (self-hosting)

Al autoalojar aplicaciones, es posible que necesite más control sobre las directivas Cache-Control.

Un caso común es controlar el período stale-while-revalidate enviado para páginas ISR. Hemos implementado dos mejoras:

  1. Ahora puede configurar el valor expireTime en next.config. Esta era anteriormente la opción experimental.swrDelta.
  2. Actualizamos el valor predeterminado a un año, asegurando que la mayoría de las CDN puedan aplicar completamente la semántica stale-while-revalidate como se pretende.

También ya no sobrescribimos valores personalizados de Cache-Control con nuestros valores predeterminados, permitiendo control total y asegurando compatibilidad con cualquier configuración de CDN.

Finalmente, hemos mejorado la optimización de imágenes al autoalojar. Anteriormente, recomendábamos instalar sharp para optimizar imágenes en su servidor Next.js. Esta recomendación a veces se pasaba por alto. Con Next.js 15, ya no necesita instalar manualmente sharp — Next.js usará sharp automáticamente al usar next start o ejecutar en modo de salida standalone.

Para aprender más, vea nuestro nuevo demo y video tutorial sobre autoalojar Next.js.

Seguridad mejorada para Acciones de Servidor (Server Actions)

Acciones de Servidor (Server Actions) son funciones del lado del servidor que pueden ser llamadas desde el cliente. Se definen añadiendo la directiva 'use server' al inicio de un archivo y exportando una función asíncrona.

Incluso si una Acción de Servidor o función de utilidad no se importa en otro lugar de su código, sigue siendo un punto final HTTP públicamente accesible. Aunque este comportamiento es técnicamente correcto, puede llevar a la exposición no intencional de dichas funciones.

Para mejorar la seguridad, hemos introducido las siguientes mejoras:

  • Eliminación de código muerto (Dead code elimination): Las Acciones de Servidor no utilizadas no tendrán sus IDs expuestos en el paquete JavaScript del lado del cliente, reduciendo el tamaño del paquete y mejorando el rendimiento.
  • IDs de acción seguros: Next.js ahora crea IDs no adivinables y no determinísticos para permitir que el cliente haga referencia y llame a la Acción de Servidor. Estos IDs se recalculan periódicamente entre compilaciones para mayor seguridad.
// app/actions.js
'use server';
 
// Esta acción **es** usada en nuestra aplicación, por lo que Next.js
// creará un ID seguro para permitir que el cliente haga referencia
// y llame a la Acción de Servidor.
export async function updateUserAction(formData) {}
 
// Esta acción **no es** usada en nuestra aplicación, por lo que Next.js
// eliminará automáticamente este código durante `next build`
// y no creará un punto final público.
export async function deleteUserAction(formData) {}

Aún debe tratar las Acciones de Servidor como puntos finales HTTP públicos. Aprenda más sobre proteger Acciones de Servidor.

Optimización del empaquetado de paquetes externos (Estable)

Empaquetar paquetes externos puede mejorar el rendimiento de inicio en frío de su aplicación. En el App Router, los paquetes externos se empaquetan por defecto, y puede excluir paquetes específicos usando la nueva opción de configuración serverExternalPackages.

En el Pages Router, los paquetes externos no se empaquetan por defecto, pero puede proporcionar una lista de paquetes para empaquetar usando la opción existente transpilePackages. Con esta opción de configuración, necesita especificar cada paquete.

Para unificar la configuración entre App y Pages Router, estamos introduciendo una nueva opción, bundlePagesRouterDependencies para igualar el empaquetado automático predeterminado del App Router. Luego puede usar serverExternalPackages para excluir paquetes específicos, si es necesario.

next.config.ts
const nextConfig = {
  // Empaquetar automáticamente paquetes externos en el Pages Router:
  bundlePagesRouterDependencies: true,
  // Excluir paquetes específicos del empaquetado para ambos App y Pages Router:
  serverExternalPackages: ['package-name'],
};
 
export default nextConfig;

Aprenda más sobre optimizar paquetes externos.

Soporte para ESLint 9

Next.js 15 también introduce soporte para ESLint 9, después del fin de vida de ESLint 8 el 5 de octubre de 2024.

Para asegurar una transición suave, Next.js sigue siendo compatible con versiones anteriores, lo que significa que puede continuar usando ESLint 8 o 9.

Si actualiza a ESLint 9, y detectamos que aún no ha adoptado el nuevo formato de configuración, Next.js aplicará automáticamente el escape hatch ESLINT_USE_FLAT_CONFIG=false para facilitar la migración.

Además, opciones obsoletas como —ext y —ignore-path serán eliminadas al ejecutar next lint. Tenga en cuenta que ESLint eventualmente prohibirá estas configuraciones antiguas en ESLint 10, por lo que recomendamos comenzar su migración pronto.

Para más detalles sobre estos cambios, consulte la guía de migración.

Como parte de esta actualización, también hemos actualizado eslint-plugin-react-hooks a v5.0.0, que introduce nuevas reglas para el uso de React Hooks. Puede revisar todos los cambios en el changelog para [email protected].

Mejoras en desarrollo y compilación (Development and Build Improvements)

HMR para Componentes de Servidor (Server Components HMR)

Durante el desarrollo, los componentes de servidor se vuelven a ejecutar al guardar. Esto significa que cualquier solicitud fetch a sus puntos finales API o servicios de terceros también se llama.

Para mejorar el rendimiento del desarrollo local y reducir posibles costos por llamadas API facturadas, ahora aseguramos que Hot Module Replacement (HMR) pueda reutilizar respuestas fetch de renders anteriores.

Aprenda más sobre la Caché HMR para Componentes de Servidor.

Generación Estática más Rápida para el Router de la Aplicación

Hemos optimizado la generación estática para mejorar los tiempos de compilación, especialmente para páginas con solicitudes de red lentas.

Anteriormente, nuestro proceso de optimización estática renderizaba las páginas dos veces: una para generar datos para la navegación del lado del cliente (client-side) y una segunda vez para renderizar el HTML para la visita inicial de la página. Ahora, reutilizamos el primer renderizado, eliminando el segundo paso, lo que reduce la carga de trabajo y los tiempos de compilación.

Además, los trabajadores de generación estática ahora comparten la caché de fetch entre páginas. Si una llamada fetch no opta por no usar la caché, sus resultados se reutilizan en otras páginas manejadas por el mismo trabajador. Esto reduce el número de solicitudes para los mismos datos.

Control Avanzado de Generación Estática (Experimental)

Hemos añadido soporte experimental para un mayor control sobre el proceso de generación estática, destinado a casos de uso avanzados que se beneficien de este mayor control.

Recomendamos mantener los valores predeterminados actuales a menos que tenga requisitos específicos, ya que estas opciones pueden aumentar el uso de recursos y provocar posibles errores de falta de memoria debido a una mayor concurrencia.

next.config.ts
const nextConfig = {
  experimental: {
    // cuántas veces Next.js reintentará generaciones de página fallidas
    // antes de fallar la compilación
    staticGenerationRetryCount: 1
    // cuántas páginas se procesarán por trabajador
    staticGenerationMaxConcurrency: 8
    // número mínimo de páginas antes de iniciar un nuevo trabajador de exportación
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

Aprende más sobre las opciones de Generación Estática.

Otros Cambios

  • [Cambio Importante] next/image: Se eliminó squoosh en favor de sharp como dependencia opcional (PR)
  • [Cambio Importante] next/image: Se cambió el valor predeterminado de Content-Disposition a attachment (PR)
  • [Cambio Importante] next/image: Error cuando src tiene espacios al inicio o al final (PR)
  • [Cambio Importante] Middleware: Se aplica la condición react-server para limitar importaciones no recomendadas de API de React (PR)
  • [Cambio Importante] next/font: Se eliminó el soporte para el paquete externo @next/font (PR)
  • [Cambio Importante] next/font: Se eliminó el hashing de font-family (PR)
  • [Cambio Importante] Caché: force-dynamic ahora establecerá un valor predeterminado no-store para la caché de fetch (PR)
  • [Cambio Importante] Config: Se habilita swcMinify (PR), missingSuspenseWithCSRBailout (PR) y outputFileTracing (PR) por defecto, y se eliminan opciones obsoletas
  • [Cambio Importante] Se elimina la auto-instrumentación para Speed Insights (ahora debe usarse el paquete dedicado @vercel/speed-insights) (PR)
  • [Cambio Importante] Se elimina la extensión .xml para rutas dinámicas de sitemap y se alinean las URLs de sitemap entre desarrollo y producción (PR)
  • [Cambio Importante] Hemos dejado de recomendar exportar export const runtime = "experimental-edge" en el Router de la Aplicación. Los usuarios ahora deben cambiar a export const runtime = "edge". Hemos añadido un codemod para realizar esto (PR)
  • [Cambio Importante] Llamar a revalidateTag y revalidatePath durante el renderizado ahora lanzará un error (PR)
  • [Cambio Importante] Los archivos instrumentation.js y middleware.js ahora usarán los paquetes React incluidos (PR)
  • [Cambio Importante] La versión mínima requerida de Node.js se ha actualizado a 18.18.0 (PR)
  • [Cambio Importante] next/dynamic: Se eliminó la propiedad obsoleta suspense y cuando el componente se usa en el Router de la Aplicación, ya no insertará un límite Suspense vacío (PR)
  • [Cambio Importante] Al resolver módulos en el Edge Runtime, no se aplicará la condición de módulo worker (PR)
  • [Cambio Importante] Se prohíbe usar la opción ssr: false con next/dynamic en Componentes del Servidor (PR)
  • [Mejora] Metadatos: Se actualizaron las variables de entorno de respaldo para metadataBase cuando se aloja en Vercel (PR)
  • [Mejora] Corrección del tree-shaking con importaciones mixtas de espacio de nombres y nombradas desde optimizePackageImports (PR)
  • [Mejora] Rutas Paralelas: Se proporcionan rutas catch-all no coincidentes con todos los parámetros conocidos (PR)
  • [Mejora] La configuración bundlePagesExternals ahora es estable y se renombró a bundlePagesRouterDependencies
  • [Mejora] La configuración serverComponentsExternalPackages ahora es estable y se renombró a serverExternalPackages
  • [Mejora] create-next-app: Los nuevos proyectos ignoran todos los archivos .env por defecto (PR)
  • [Mejora] Las opciones outputFileTracingRoot, outputFileTracingIncludes y outputFileTracingExcludes han sido actualizadas desde experimental y ahora son estables (PR)
  • [Mejora] Se evita mezclar archivos CSS globales con archivos CSS module más profundos en el árbol (PR)
  • [Mejora] El manejador de caché puede especificarse mediante la variable de entorno NEXT_CACHE_HANDLER_PATH (PR)
  • [Mejora] El Router de Páginas ahora soporta tanto React 18 como React 19 (PR)
  • [Mejora] El Error Overlay ahora muestra un botón para copiar la URL del Inspector de Node.js si el inspector está habilitado (PR)
  • [Mejora] Los prefetchs del cliente en el Router de la Aplicación ahora usan el atributo priority (PR)
  • [Mejora] Next.js ahora proporciona una función unstable_rethrow para relanzar errores internos de Next.js en el Router de la Aplicación (PR)
  • [Mejora] unstable_after ahora puede usarse en páginas estáticas (PR)
  • [Mejora] Si un componente next/dynamic se usa durante SSR, el chunk será prefetcheado (PR)
  • [Mejora] La opción esmExternals ahora es compatible con el Router de la Aplicación (PR)
  • [Mejora] La opción experimental.allowDevelopmentBuild puede usarse para permitir NODE_ENV=development con next build con fines de depuración (PR)
  • [Mejora] Las transformaciones de Server Action ahora están deshabilitadas en el Router de Páginas (PR)
  • [Mejora] Los trabajadores de compilación ahora evitarán que la compilación se quede colgada cuando salen (PR)
  • [Mejora] Al redirigir desde una Server Action, las revalidaciones ahora se aplicarán correctamente (PR)
  • [Mejora] Los parámetros dinámicos ahora se manejan correctamente para rutas paralelas en el Edge Runtime (PR)
  • [Mejora] Las páginas estáticas ahora respetarán staleTime después de la carga inicial (PR)
  • [Mejora] vercel/og actualizado con una corrección de fuga de memoria (PR)
  • [Mejora] Se actualizaron los tiempos de parche para permitir el uso de paquetes como msw para simulación de APIs (PR)
  • [Mejora] Las páginas prerenderizadas deben usar staleTime estático (PR)

Para aprender más, consulta la guía de actualización.

Colaboradores

Next.js es el resultado del trabajo combinado de más de 3,000 desarrolladores individuales, socios de la industria como Google y Meta, y nuestro equipo central en Vercel. Este lanzamiento fue posible gracias a:

Un enorme agradecimiento a @AbhiShake1, @Aerilym, @AhmedBaset, @AnaTofuZ, @Arindam200, @Arinji2, @ArnaudFavier, @ArnoldVanN, @Auxdible, @B33fb0n3, @Bhavya031, @Bjornnyborg, @BunsDev, @CannonLock, @CrutchTheClutch, @DeepakBalaraman, @DerTimonius, @Develliot, @EffectDoplera, @Ehren12, @Ethan-Arrowood, @FluxCapacitor2, @ForsakenHarmony, @Francoscopic, @Gomah, @GyoHeon, @Hemanshu-Upadhyay, @HristovCodes, @HughHzyb, @IAmKushagraSharma, @IDNK2203, @IGassmann, @ImDR, @IncognitoTGT, @Jaaneek, @JamBalaya56562, @Jeffrey-Zutt, @JohnGemstone, @JoshuaKGoldberg, @Julian-Louis, @Juneezee, @KagamiChan, @Kahitar, @KeisukeNagakawa, @KentoMoriwaki, @Kikobeats, @KonkenBonken, @Kuboczoch, @Lada496, @LichuAcu, @LorisSigrist, @Lsnsh, @Luk-z, @Luluno01, @M-YasirGhaffar, @Maaz-Ahmed007, @Manoj-M-S, @ManuLpz4, @Marukome0743, @MaxLeiter, @MehfoozurRehman, @MildTomato, @MonstraG, @N2D4, @NavidNourani, @Nayeem-XTREME, @Netail, @NilsJacobsen, @Ocheretovich, @OlyaPolya, @PapatMayuri, @PaulAsjes, @PlagueFPS, @ProchaLu, @Pyr33x, @QiuranHu, @RiskyMH, @Sam-Phillemon9493, @Sayakie, @Shruthireddy04, @SouthLink, @Strift, @SukkaW, @Teddir, @Tim-Zj, @TrevorSayre, @Unsleeping, @Willem-Jaap, @a89529294, @abdull-haseeb, @abhi12299, @acdlite, @actopas, @adcichowski, @adiguno, @agadzik, @ah100101, @akazwz, @aktoriukas, @aldosch, @alessiomaffeis, @allanchau, @alpedia0, @amannn, @amikofalvy, @anatoliik-lyft, @anay-208, @andrii-bodnar, @anku255, @ankur-dwivedi, @aralroca, @archanaagivale30, @arlyon, @atik-persei, @avdeev, @baeharam, @balazsorban44, @bangseongbeom, @begalinsaf, @bennettdams, @bewinsnw, @bgw, @blvdmitry, @bobaaaaa, @boris-szl, @bosconian-dynamics, @brekk, @brianshano, @cfrank, @chandanpasunoori, @chentsulin, @chogyejin, @chrisjstott, @christian-bromann, @codeSTACKr, @coderfin, @coltonehrman, @controversial, @coopbri, @creativoma, @crebelskydico, @crutchcorn, @darthmaim, @datner, @davidsa03, @delbaoliveira, @devjiwonchoi, @devnyxie, @dhruv-kaushik, @dineshh-m, @diogocapela, @dnhn, @domdomegg, @domin-mnd, @dvoytenko, @ebCrypto, @ekremkenter, @emmerich, @flybayer, @floriangosse, @forsakenharmony, @francoscopic, @frys, @gabrielrolfsen, @gaojude, @gdborton, @greatvivek11, @gnoff, @guisehn, @GyoHeon, @hamirmahal, @hiro0218, @hirotomoyamada, @housseindjirdeh, @hungdoansy, @huozhi, @hwangstar156, @iampoul, @ianmacartney, @icyJoseph, @ijjk, @imddc, @imranolas, @iscekic, @jantimon, @jaredhan418, @jeanmax1me, @jericopulvera, @jjm2317, @jlbovenzo, @joelhooks, @joeshub, @jonathan-ingram, @jonluca, @jontewks, @joostmeijles, @jophy-ye, @jordienr, @jordyfontoura, @kahlstrm, @karlhorky, @karlkeefer, @kartheesan05, @kdy1, @kenji-webdev, @kevva, @khawajaJunaid, @kidonng, @kiner-tang, @kippmr, @kjac, @kjugi, @kshehadeh, @kutsan, @kwonoj, @kxlow, @leerob, @lforst, @li-jia-nan, @liby, @lonr, @lorensr, @lovell, @lubieowoce, @luciancah, @luismiramirez, @lukahartwig, @lumirlumir, @luojiyin1987, @mamuso, @manovotny, @marlier, @mauroaccornero, @maxhaomh, @mayank1513, @mcnaveen, @md-rejoyan-islam, @mehmetozguldev, @mert-duzgun, @mirasayon, @mischnic, @mknichel, @mobeigi, @molebox, @mratlamwala, @mud-ali, @n-ii-ma, @n1ckoates, @nattui, @nauvalazhar, @neila-a, @neoFinch, @niketchandivade, @nisabmohd, @none23, @notomo, @notrab, @nsams, @nurullah, @okoyecharles, @omahs, @paarthmadan, @pathliving, @pavelglac, @penicillin0, @phryneas, @pkiv, @pnutmath, @qqww08, @r34son, @raeyoung-kim, @remcohaszing, @remorses, @rezamauliadi, @rishabhpoddar, @ronanru, @royalfig, @rubyisrust, @ryan-nauman, @ryohidaka, @ryota-murakami, @s-ekai, @saltcod, @samcx, @samijaber, @sean-rallycry, @sebmarkbage, @shubh73, @shuding, @sirTangale, @sleevezip, @slimbde, @soedirgo, @sokra, @sommeeeer, @sopranopillow, @souporserious, @srkirkland, @steadily-worked, @steveluscher, @stipsan, @styfle, @stylessh, @syi0808, @symant233, @tariknh, @theoludwig, @timfish, @timfuhrmann, @timneutkens, @tknickman, @todor0v, @tokkiyaa, @torresgol10, @tranvanhieu01012002, @txxxxc, @typeofweb, @unflxw, @unstubbable, @versecafe, @vicb, @vkryachko, @wbinnssmith, @webtinax, @weicheng95, @wesbos, @whatisagi, @wiesson, @woutvanderploeg, @wyattjoh, @xiaohanyu, @xixixao, @xugetsu, @yosefbeder, @ypessoa, @ytori, @yunsii, @yurivangeffen, @z0n, @zce, @zhawtof, @zsh77, y @ztanner por su ayuda!