[Jonathangarrido]

Descripción

• Vite 8.3.5 y @vitejs/plugin-react 6.1.2 reemplazan a Vite 2.9. Los alias de tsconfig se resuelven con resolve.tsconfigPaths y se quita vite-tsconfig-paths.
• build.target: 'es2019' mantiene la compatibilidad del bundle y cssFileName: 'style' conserva dist/style.css.
• Jest 27, ts-jest y sus dependencias se reemplazan por Vitest 5 con jsdom 29.1.1. El setup pasa a src/test/vitest-setup.ts y las pruebas usan vi.fn y vi.mock.
• pool: 'vmThreads' y maxWorkers: '50%' reducen el tiempo de la suite a la mitad.
• Se excluyen barrels, __mocks__ y .d.ts del reporte de cobertura.
• Se agregan pruebas a los componentes con cobertura baja: Progress, DateStatus, IconSelection, maxWidthCoursesList, UserWay, UserWayCookie, NavBarButton, ArrowRight, Avatar, PaymentModal, AlertInfo, CalendarDropdown y el hook useParseEvents.
• Bugfixes:
  • Avatar ignora espacios dobles o al inicio al armar las iniciales.
  • PaymentModal tiene su propio displayName y AlertInfo deja de llamarse ArrowRight.
  • El left inválido '34pxpx' del menú de CalendarDropdown pasa a 0. Medido en npm run docu, la posición del menú no cambia.
• Se mantiene TypeScript 4.9.5: con TS 5 o superior, los tipos de Chakra 1.8 dan TS2590.
• Se fija overrides de @babel/plugin-transform-runtime para evitar un ERESOLVE del peer opcional de @rolldown/plugin-babel.

Motivación y contexto

Vite 2.9 y Jest 27 estaban desactualizados. Vite 8 y Vitest 5 son las versiones actuales y Vitest reutiliza la configuración de Vite. Al migrar, las pruebas de los componentes con cobertura baja se completaron para que el reporte de cobertura sea útil.

¿Cómo puede ser probado esto?

1. npm ci y npm run test: deben pasar 355 pruebas en 28 archivos.
2. npm run lint:check y npm run ts-compile-check: deben pasar sin errores.
3. npm run build y npm run deploy: deben generar dist/eclass-ui-kit.es.js, dist/eclass-ui-kit.umd.js y dist/style.css.
4. npm run docu y abrir /organisms/calendardropdown: el menú de escritorio debe abrir en la misma posición que en main, y en mobile no debe cambiar.
5. Validar en v8 con yalc, como indica .claude/rules/commands.md.

Tipos de cambios

• Bugfix (cambio ininterrumpido que soluciona un problema)
• Feature (cambio sin interrupciones que agrega funcionalidad)
• Breaking change (corrección o característica que haría que la funcionalidad existente no funcionara como se esperaba)
• Documentación (solo documentación, sin cambios en el código de la app)