BackVolver al blog

Next.js 15 RC 2

El segundo Release Candidate (RC) de Next.js 15 ya está disponible. Esta versión te permite probar las últimas funciones antes del próximo lanzamiento estable.

Tras el anuncio del primer Release Candidate de Next.js 15 en mayo, hemos estado preparando un segundo Release Candidate basado en sus comentarios. Esto es en lo que hemos estado trabajando:

Prueba el Release Candidate (RC2) de Next.js 15 hoy:

# Usa el nuevo CLI de actualización automatizado
npx @next/codemod@canary upgrade rc
 
# ...o actualiza manualmente
npm install next@rc react@rc react-dom@rc

Nota: Este Release Candidate incluye todos los cambios del RC anterior.

Actualizaciones simplificadas con CLI 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 sencillas, hemos lanzado un CLI codemod mejorado:

npx @next/codemod@canary upgrade rc

Esta herramienta te ayuda a actualizar tu base de código a las últimas versiones estables o preliminares. El CLI actualizará tus dependencias, mostrará los codemods disponibles y te guiará para aplicarlos. La etiqueta de distribución especificada en la línea de comandos (@rc, @canary, etc.) determina la versión a la que actualizar.

Aprende más sobre codemods de Next.js.

Turbopack para desarrollo

Turbopack para desarrollo local se volverá estable en el lanzamiento general de Next.js 15, aunque seguirá siendo opcional. Puedes probarlo hoy ejecutando:

next dev --turbo

Gracias a los miles de desarrolladores que participaron en pruebas, reporte de problemas y verificación de correcciones durante las fases beta y release candidate de Turbopack, hemos resuelto 54 issues en GitHub desde el primer Release Candidate de Next.js 15. Junto con este esfuerzo comunitario, nuestras pruebas internas en vercel.com, v0.dev y nextjs.org ayudaron a identificar numerosas mejoras adicionales.

En los últimos tres meses, nos hemos enfocado en optimizar el rendimiento de compilación en frío. Comparado con el lanzamiento anterior, hemos visto:

  • Reducción del 25–35% en uso de memoria.
  • 30–50% más rápido en compilación para páginas grandes con miles de módulos.

Seguiremos optimizando estas áreas en futuros lanzamientos.

Mirando hacia adelante, el equipo de Turbopack está avanzando significativamente en caché persistente, reducción de uso de memoria y Turbopack para next build—con 96% de las pruebas pasando.

Nota: Consulta todas las funciones soportadas y no soportadas de Turbopack.

APIs de solicitud asíncronas (Cambio importante)

En el Renderizado del Lado del Servidor 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 sencilla, 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:

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 Next.js a las nuevas APIs.

Seguridad mejorada para Acciones de Servidor

Acciones de Servidor 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 utilitaria no se importa en otro lugar de tu código, sigue siendo un endpoint HTTP públicamente accesible. Aunque este comportamiento es técnicamente correcto, puede llevar a una exposición no intencional de dichas funciones.

Para mejorar la seguridad, hemos introducido las siguientes mejoras:

  • Eliminación de código muerto: Las Acciones de Servidor no utilizadas no tendrán sus IDs expuestos en el bundle JavaScript del lado del cliente, reduciendo el tamaño del bundle y mejorando el rendimiento.
  • IDs de acción seguros: Next.js ahora crea IDs imposibles de adivinar 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 construcciones para mayor seguridad.
// app/actions.js
'use server';
 
// Esta acción **sí** se usa 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** se usa en nuestra aplicación, por lo que Next.js
// eliminará automáticamente este código durante `next build`
// y no creará un endpoint público.
export async function deleteUserAction(formData) {}

Aún debes tratar las Acciones de Servidor como endpoints HTTP públicos. Aprende más sobre proteger Acciones de Servidor.

Indicador de Ruta Estática

Next.js ahora muestra un Indicador de Ruta Estática durante el desarrollo para ayudarte 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 tus páginas.

También puedes 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.

Aprende más sobre el Indicador de Ruta Estática, que puede desactivarse.

Componente <Form>

El nuevo componente <Form> extiende el elemento HTML <form> con prefetching, navegación del lado del cliente 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.

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 se precargan, haciendo la navegación más rápida.
  • Navegación del lado del cliente: Al enviar, los layouts compartidos y el estado del cliente se preservan.
  • Mejora progresiva: 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: Esto está abreviado para propósitos de demostración.
// No se recomienda para 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árgala
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // captura todos los campos del formulario y dispara 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} />
}

Aprende 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:

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

Aprende más sobre soporte para TypeScript en Next.js.

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 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 eliminarse.

Además, hemos colaborado con Sentry en el diseño de un nuevo hook onRequestError que puede usarse 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 tu 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() {
  // inicializa el SDK de tu proveedor de observabilidad favorito
}

Aprende más sobre la función onRequestError function.

Mejoras en desarrollo y construcción

HMR para Componentes de Servidor

Durante el desarrollo, los componentes del servidor se vuelven a ejecutar cuando se guardan. Esto significa que cualquier solicitud fetch a tus endpoints API o servicios de terceros también se llama.

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

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

Generación estática más rápida para App Router

Hemos optimizado la generación estática para mejorar los tiempos de construcció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 navegación del lado del cliente y una segunda para renderizar el HTML para la visita inicial. Ahora, reutilizamos el primer render, eliminando el segundo paso, reduciendo carga de trabajo y tiempos de construcción.

Además, los workers de generación estática ahora comparten la caché fetch entre páginas. Si una llamada fetch no opta por no usar caché, sus resultados se reutilizan por otras páginas manejadas por el mismo worker. 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 una gestión más granular.

Recomendamos mantener las configuraciones predeterminadas actuales a menos que tenga requisitos específicos, ya que estas opciones pueden aumentar el uso de recursos y provocar errores de memoria insuficiente debido a una mayor concurrencia.

const nextConfig = {
  experimental: {
	  // cuántas veces Next.js reintentará generaciones de página fallidas
	  // antes de marcar el build como fallido
    staticGenerationRetryCount: 1
    // cantidad de páginas procesadas por worker
    staticGenerationMaxConcurrency: 8
    // mínimo de páginas requeridas para iniciar un nuevo worker de exportación
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

Más información sobre las opciones de Generación Estática.

Mejoras para Auto-hospedaje

Al auto-hospedar aplicaciones, puede necesitar mayor control sobre las directivas Cache-Control.

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

  1. Ahora puede configurar el valor expireTime en next.config. Anteriormente era la opción experimental.swrDelta.
  2. Actualizamos el valor predeterminado a un año, garantizando que la mayoría de CDNs apliquen correctamente la semántica stale-while-revalidate.

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

Finalmente, mejoramos la optimización de imágenes en entornos auto-hospedados. 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 sharp manualmente — Next.js lo usará automáticamente con next start o en modo de salida standalone.

Para más detalles, vea nuestro nuevo video demostrativo y tutorial sobre auto-hospedaje con Next.js.

Soporte para ESLint 9

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

Para garantizar una transición fluida, Next.js mantiene compatibilidad con versiones anteriores, permitiendo usar tanto ESLint 8 como 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 parámetro ESLINT_USE_FLAT_CONFIG=false para facilitar la migración.

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

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

Como parte de esta actualización, también hemos mejorado 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 registro de cambios de [email protected].

Otros Cambios

  • Todos los cambios descritos previamente en el artículo del RC 1
  • [Cambio Rompedor] Hemos marcado como obsoleto export const runtime = "experimental-edge" en el App Router. Los usuarios deben usar export const runtime = "edge". Hemos añadido un codemod para realizar esto (PR)
  • [Cambio Rompedor] Llamar a revalidateTag y revalidatePath durante el renderizado ahora lanzará un error (PR)
  • [Cambio Rompedor] Los archivos instrumentation.js y middleware.js ahora usarán los paquetes React vendidos (PR)
  • [Cambio Rompedor] La versión mínima requerida de Node.js ahora es 18.18.0 (PR)
  • [Cambio Rompedor] next/dynamic: se eliminó el prop obsoleto suspense y cuando el componente se usa en el App Router, ya no insertará un límite de Suspense vacío (PR)
  • [Cambio Rompedor] Al resolver módulos en el Edge Runtime, no se aplicará la condición de módulo worker (PR)
  • [Cambio Rompedor] Se prohibió usar la opción ssr: false con next/dynamic en Server Components (PR)
  • [Mejora] Las opciones outputFileTracingRoot, outputFileTracingIncludes y outputFileTracingExcludes han salido de la fase experimental y ahora son estables (PR)
  • [Mejora] Evita mezclar archivos CSS globales con archivos de módulos CSS en niveles más profundos del árbol (PR)
  • [Mejora] El manejador de caché puede especificarse mediante la variable de entorno NEXT_CACHE_HANDLER_PATH (PR)
  • [Mejora] El Pages Router ahora soporta React 18 y React 19 (PR)
  • [Mejora] El Error Overlay ahora muestra un botón para copiar la URL del Inspector de Node.js si está habilitado (PR)
  • [Mejora] Los prefetchs de cliente en el App Router ahora usan el atributo priority (PR)
  • [Mejora] Next.js ahora proporciona una función unstable_rethrow para relanzar errores internos en el App Router (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 se pre-cargará (PR)
  • [Mejora] La opción esmExternals ahora es compatible con el App Router (PR)
  • [Mejora] La opción experimental.allowDevelopmentBuild permite usar NODE_ENV=development con next build para depuración (PR)
  • [Mejora] Las transformaciones de Server Actions están deshabilitadas en el Pages Router (PR)
  • [Mejora] Los workers de build ahora evitan que el proceso se quede colgado al terminar (PR)
  • [Mejora] Al redirigir desde una Server Action, las revalidaciones ahora se aplican correctamente (PR)
  • [Mejora] Los parámetros dinámicos ahora se manejan correctamente en rutas paralelas en el Edge Runtime (PR)
  • [Mejora] Las páginas estáticas ahora respetan staleTime después de la carga inicial (PR)
  • [Mejora] Actualización de vercel/og con corrección de fuga de memoria (PR)
  • [Mejora] Actualización de tiempos de parche para permitir uso de paquetes como msw para simulación de APIs (PR)

Contribuidores

Next.js es el resultado del trabajo combinado de más de 3,000 desarrolladores individuales y nuestro equipo central en Vercel. Esta versión fue posible gracias a:

Un enorme agradecimiento a todos los contribuidores mencionados por su ayuda.