Eliminación de dependencias obsoletas de JavaScript: CRA, Moment, jQuery y más

La mayoría de los proyectos en JavaScript incluyen algunas dependencias que fueron la elección obvia cuando se creó el repositorio y que ahora son una carga innecesaria: paquetes grandes, vulnerabilidades sin corregir, incompatibilidades con entornos modernos o funciones que la plataforma ahora ofrece de forma gratuita. Ninguna de ellas provoca problemas de repente, y ese es precisamente el motivo por el cual persisten. Esta guía analiza las bibliotecas y herramientas que están obsoletas, congeladas en modo de mantenimiento o perdiendo terreno gradualmente, explica por qué cada una quedó atrás y indica cuáles son sus sustitutos para que pueda planificar las migraciones de manera deliberada en lugar de bajo presión.

Herramientas de construcción y estructuración

Create React App

Durante años, Create React App (CRA) fue la herramienta con la que se iniciaban los proyectos en React. A principios de 2025, el equipo de React lo declaró oficialmente obsoleto como punto de partida para nuevas aplicaciones, y ya no recibe actualizaciones significativas, por lo que los problemas de seguridad en su cadena de herramientas permanecen sin resolver. Sus cifras de descargas han ido disminuyendo rápidamente a medida que los equipos pasan a otras opciones.

Las razones subyacentes son estructurales: nadie lo mantiene activamente, sus suposiciones sobre el empaquetado y los servidores de desarrollo están desactualizadas, y las alternativas cubren requisitos modernos como el renderizado en servidor, compilaciones más rápidas y una mejor experiencia para los desarrolladores sin necesidad de configuración adicional. Algunas buenas alternativas son:

• Vite con @vitejs/plugin-react para las aplicaciones de página única típicas
• Next.js, Remix/React Router u otro framework completo si la aplicación necesita un router, convenciones para obtener datos o código del lado del servidor

Parcel o Rsbuild si deseas algo más ligero

Dado que una aplicación CRA consiste principalmente en código React estándar más una configuración de compilación oculta, la migración suele ser mucho menor de lo que esperan los equipos: solo se cambia la herramienta de compilación, se traslada el punto de entrada HTML y las convenciones de variables de entorno, mientras que los componentes en sí permanecen sin cambios. Si estás comenzando desde cero, la guía paso a paso en nuestra guía de configuración para React y Vite aborda los nuevos estándares.

Webpack para proyectos nuevos

Webpack está lejos de estar obsoleto. Un gran número de aplicaciones en producción aún se construyen con él, y eso no cambiará pronto. Lo que está disminuyendo es su participación en nuevos proyectos, principalmente debido a la complejidad de su configuración y a tiempos de inicio más lentos en comparación con herramientas más recientes. Para trabajos front-end desde cero, Vite es la opción predeterminada actual, con configuraciones basadas en Rspack y esbuild como otras alternativas sólidas. Webpack sigue siendo una buena opción para configuraciones existentes muy complejas, pero rara vez debería ser el punto de partida para un nuevo proyecto. Para una comparación más detallada de las opciones, consulte cómo elegir un bundler.

Bibliotecas que la plataforma ha incorporado

Moment.js

Casi todos los desarrolladores de JavaScript han utilizado Moment.js en algún momento. Sus propios mantenedores lo han descrito durante mucho tiempo como un proyecto heredado en modo de mantenimiento. Es grande, sus objetos son mutables por defecto (una fuente común de errores cuando una fecha se modifica en un lugar y se observa en otro), y no permite una optimización eficaz mediante tree-shaking.

El manejo nativo de fechas ha mejorado, y ahora existen bibliotecas pequeñas e inmutables que realizan la misma función con un mejor rendimiento. Sus opciones, aproximadamente en orden de preferencia:

• Intl.DateTimeFormat para un formato sensible a la configuración regional
• Temporal, la nueva API integrada para fechas y horas por la que los desarrolladores esperaron años; se ha ido implementando en diferentes entornos y navegadores; verifique el soporte actual para sus objetivos antes de confiar en ella
• date-fns, Luxon o Day.js si aún es necesario utilizar una biblioteca

Si Moment sigue estando en su árbol de dependencias, programe la migración. La reducción del tamaño del paquete por sí sola suele ser considerable.

jQuery

jQuery resolvió problemas reales entre navegadores en la década de 2010. Para el código nuevo actualmente casi nunca está justificado, ya que las API DOM estandarizadas, fetch y los frameworks de componentes cubren todo lo que antes era necesario para solucionar esos problemas. El JavaScript puro con querySelector, classList, addEventListener y fetch nativo maneja la mayor parte de las tareas directas con el DOM, y React, Vue, Svelte o Solid se encargan cuando se necesitan interfaces basadas en componentes. Los conjuntos de código heredados mantendrán a jQuery activo durante años, y eso está bien, pero recurrir a él en un proyecto completamente nuevo es una señal de alerta.

Lodash y Underscore

Antes de ES2015, Lodash era casi obligatorio. Ahora la mayoría de sus herramientas tienen equivalentes nativos: métodos de array como map, filter y reduce, Object.entries, enlace opcional, unión con valores nulos y más. Es difícil justificar la inclusión de toda la biblioteca, o incluso de partes importantes de ella, solo para usar un puñado de funciones. Empiece con el propio lenguaje y añada herramientas específicas únicamente cuando la API nativa realmente sea insuficiente, como en el caso de la igualdad profunda o del desaceleramiento de eventos. Nuestro artículo sobre características nativas que reemplazan las dependencias de herramientas muestra ejemplos concretos de tales reemplazos.

Pruebas y redes

Enzyme

request y node-fetch v2

request fue oficialmente obsoleto hace mucho tiempo y ya no recibe parches de seguridad, por lo que cualquier uso restante representa un riesgo evidente. Las descargas de node-fetch v2 también han disminuido drásticamente, ya que Node.js 18 y versiones posteriores incluyen un fetch global (en las primeras versiones se marcó como experimental, así que confirme su comportamiento en su versión de Node). Utilice el fetch nativo, que ahora funciona en las versiones modernas de Node y en todos los navegadores actuales. Cuando necesite intentos repetidos, interceptores o una transmisión más avanzada, considere usar undici, ky o got.

Otros elementos que vale la pena monitorear

Existen algunos cambios más que merecen incluirse en su lista de actualizaciones:

• Según su calendario de lanzamientos, ESLint 9.x llegará al final de su soporte en agosto de 2026; planifique la migración a la línea v10 y verifique las fechas en el sitio oficial de ESLint.

El AWS SDK para JavaScript v2 ya no cuenta con soporte. Pase a los clientes modulares v3 ubicados en @aws-sdk/*, que también le permiten importar solo los clientes que utiliza.

Los frameworks antiguos como vue-cli y Nuxt 2 son, en efecto, obsoletos.

Node.js sigue eliminando funciones integradas y APIs antiguas a medida que el entorno de ejecución se moderniza, por lo que debe leer la lista oficial de funciones obsoletas antes de cada actualización a una versión mayor.

Entornos de ejecución como Bun incluyen más funcionalidades de forma nativa, lo que reduce aún más la necesidad de muchos paquetes utilitarios pequeños.

Una rutina para mantener las dependencias actualizadas

No basta con reemplazar estas bibliotecas una sola vez; el objetivo es adoptar un hábito que impida que se acumulen nuevas dependencias obsoletas.

1. Efectúe auditorías periódicas de package.json y ejecute npm outdated y npm audit para detectar cualquier desfase.

Preferir las funciones nativas de la plataforma una vez que estén estables y tengan un amplio soporte en los entornos a los que se dirige.

Seguir atentamente los anuncios de descontinuación publicados por React, Node.js, ESLint y los mantenedores de sus bibliotecas principales.

Considerar que “todavía funciona” es un estado temporal. Las actualizaciones de seguridad continuas y el apoyo del ecosistema superan la comodidad de dejar las cosas como están.

Establecer como predeterminado para nuevos proyectos herramientas modernas: Vite, el método fetch integrado, Temporal cuando esté disponible, y las versiones más recientes de los frameworks principales.

Un equilibrio útil a tener en cuenta: no toda dependencia heredada merece una reescritura inmediata. Una herramienta interna estable que utilice jQuery o Webpack puede costar más en migración de lo que jamás ahorrará. Priorice según el nivel de exposición. Todo aquello que no se mantiene y que interactúa con la red, las entradas del usuario o su pipeline de compilación (request, CRA, AWS SDK v2) debe ser prioritario; las librerías cuyo tamaño importa, como Moment y Lodash, vienen en segundo lugar; la modernización puramente estilística puede esperar.

Puntos clave

• Los paquetes obsoletos y sin mantenimiento representan primero un problema de seguridad y luego uno de rendimiento, por lo que ordene las migraciones según el riesgo.
• Muchas de las herramientas tradicionales (Moment, Lodash, jQuery, request) han sido integradas por el lenguaje, el DOM o el entorno de ejecución, lo que hace que su reemplazo sea más pequeño que la dependencia original.

Las migraciones de herramientas como de CRA a Vite suelen afectar la configuración, no el código de la aplicación.

Una auditoría regular y el uso por defecto de herramientas modernas en nuevos proyectos mantendrán esta lista corta en el futuro.