Desde el lanzamiento de Vite 2.0 en febrero de 2021, la cantidad de usuarios del proyecto Vite ha crecido muy rápidamente y pronto alcanzó 1 millón de descargas de npm por semana, convirtiéndose en uno de los proyectos con las descargas de npm más altas. Al mismo tiempo, la comunidad de Vite se está volviendo cada vez más activa y ha formado una ecología de comunidad muy grande, lo que ha traído muchos cambios a todo el campo frontal, como:
- Los principales marcos front-end, incluidos Nuxt 3, SvelteKit, Astro, StoryBook, etc., han adoptado Vite como una solución de construcción integrada.
- Nació Vitest, la herramienta de prueba basada en Vite, que se convirtió en una nueva generación de soluciones de prueba para reemplazar a Jest.
Ahora es julio de 2023 y la versión Vite 4.0 se lanzó hace varios meses, pero aún queremos presentar algunos cambios que trajo Vite 3.0.
1. Nueva documentación de VitePress
Para el usuario, cuando se trata de actualizar el marco, la documentación es naturalmente la parte más importante. Ahora puede ir directamente al sitio vitejs.dev para experimentar la versión v3 de la documentación Actualmente, la documentación también se crea con VitePress.
No solo Vite, sino también algunos otros proyectos en el ecosistema de Vite usan VitePress para crear sitios de documentos, como Vitest , vite-plugin-pwa y los propios documentos de VitePress . También recomiendo a todos que usen VitePress como uno de sus sitios de creación de documentos. soluciones
2. Actualizaciones en la fase de desarrollo
2.1 Actualizaciones de la CLI
Al ejecutar el comando vite para iniciar el proyecto, la interfaz de la terminal será diferente a la anterior y, lo que es más importante, para evitar el conflicto de puertos entre el servicio de desarrollo de Vite y otras aplicaciones, el número de puerto predeterminado ha cambiado de 3000 a 5173.
2.2 Estrategia de conexión de WebSocket lista para usar
Hay un problema en Vite 2, es decir, en presencia de un proxy (como Web IDE), necesitamos configurar manualmente WebSocket para que HMR surta efecto. Actualmente, Vite ha incorporado un conjunto más completo de estrategias de conexión de WebSocket para cumplir automáticamente con los requisitos de HMR de más escenarios.
2.3 Mejora del rendimiento del servicio de arranque en frío
Vite 3.0 ha trabajado mucho en el inicio en frío del servicio para maximizar la velocidad de inicio del proyecto. En primer lugar, hagamos un balance de algunos problemas de arranque en frío del servicio en la etapa Vite 2.x.
Desde Vite 2.0 hasta la versión 2.9, Vite creará previamente las dependencias antes de que comience el servicio, es decir, usará Esbuild para escanear las dependencias utilizadas en el proyecto (Escanear) y luego las empaquetará una vez (Optimizar).
Sin embargo, esto crea dos problemas:
- Confiar en la compilación previa bloqueará el inicio de Dev Server, pero Dev Server puede iniciarse normalmente sin bloquearse.
- Cuando algunos complementos de Vite inyectan manualmente declaraciones de importación, como llamar a babel-plugin-import para agregar el botón de importación desde 'antd/lib/button', conducirá a una compilación previa secundaria de Vite, porque el código de importación de antd/lib/ El botón creado por la inyección del complemento Vite es una dependencia que se encuentra cuando el servidor de desarrollo se está ejecutando y no se puede escanear durante la fase de inicio en frío.
La llamada compilación previa secundaria incluye dos pasos: uno es compilar previamente todas las dependencias en su totalidad y el otro es volver a cargar la página para cargar el código dependiente más reciente debido a las actualizaciones de dependencia. Esto conducirá a una disminución significativa en el rendimiento del servidor de desarrollo, especialmente en escenarios donde hay muchas dependencias nuevas y es fácil que el navegador se atasque.
Y vite-plugin-optimize-persist es para resolver los problemas causados por la segunda compilación previa y registrar las dependencias escaneadas por el tiempo de ejecución del servidor de desarrollo de manera persistente, de modo que la primera compilación previa pueda ser percibida y evitar la segunda. pre-construcción sucedió.
En la versión 2.9, Vite ha refactorizado la lógica preconstruida como un todo, y el efecto final es el siguiente:
-
Una vez que se inicia el servidor de desarrollo, la compilación previa (fase de optimización) se ejecuta en segundo plano, es decir, la compilación previa ya no bloquea el inicio del servidor de desarrollo y solo necesita esperar a que se complete la fase de escaneo. pero normalmente la sobrecarga de esta fase es muy pequeña.
-
Si algunas dependencias solo se descubren cuando Dev Server se está ejecutando, Vite reutilizará los productos preconstruidos existentes tanto como sea posible e intentará no recargarlos.
¿Ese problema está completamente resuelto? De hecho, no lo es. En algunos escenarios, Vite todavía necesita inevitablemente una segunda compilación previa. Como en el siguiente ejemplo:
Tanto A como B son dependencias de terceros del proyecto y también dependen de C. Luego, cuando Vite preconstruya A, empaquetará A y C juntos. Sin embargo, Vite descubrió que depende de B en tiempo de ejecución, y A y B deben compartir el código de C, por lo que el código de C se puede extraer en un fragmento común, por lo que el producto preconstruido de A puede haber cambiado antes, entonces, en este momento, Vite debe actualizar la página a la fuerza para permitir que el navegador use el último producto preconstruido. Este sigue siendo un proceso secundario de precompilación (todas las dependencias reempaquetadas + recarga de página). En general, la versión 2.9 resuelve el problema del inicio del servicio de bloqueo previo a la compilación, pero no resuelve completamente el problema de la compilación previa secundaria.
Pero en Vite 3.0, el problema de la preconstrucción secundaria también se ha resuelto fundamentalmente. ¿Cómo lo hizo Vite 3.0?
La solución principal es retrasar el procesamiento, es decir, retrasar el comportamiento de compilación previa hasta la etapa final de la carga de la página. En este momento, Vite ha compilado todos los archivos fuente y puede registrar con precisión todas las dependencias que deben compilarse previamente. (incluidos los complementos de Vite agregados Algunas dependencias), y luego preconstruir de manera uniforme y responder al producto preconstruido para el navegador.
Por lo tanto, en comparación con Vite 2.0, Vite 3.0 se optimiza en la fase de arranque en frío principalmente en dos aspectos:
- La compilación previa ya no bloqueará el inicio de Dev Server y realmente logrará el efecto del inicio del servicio en segundos;
- Prevenir fundamentalmente la aparición de preconstrucción secundaria.
2.4 actualización de sintaxis de import.meta.glob
Vite 3.0 reescribe la implementación de import.meta.glob, admite una sintaxis glob más flexible y agrega las siguientes características:
- Coincidencia de patrones múltiples
import.meta.glob(["./dir/*.js", "./another/*.js"]);
- Patrón negativo (!)
import.meta.glob(["./dir/*.js", "!**/bar.js"]);
- Las importaciones con nombre pueden hacer mejor Tree Shaking
import.meta.glob("./dir/*.js", { import: "setup" });
- Parámetros de consulta personalizados
import.meta.glob("./dir/*.js", { query: { custom: "data" } });
- Especifique el modo impaciente, reemplace el import.meta.globEager original
import.meta.glob("./dir/*.js", { eager: true });
3. Actualización de la etapa de producción
3.1 Los productos SSR utilizan el formato ESM de forma predeterminada
En la ecología comunitaria actual, muchos marcos de SSR ya utilizan el formato ESM como formato de producto predeterminado. Vite 3.0 también acepta activamente a la comunidad y admite SSR para crear productos que se empaquetan en formato ESM de forma predeterminada.
3.2 Soporte de base relativa
Vite 3.0 es oficialmente compatible con Relative Base (es decir, configure base: ''), que se usa principalmente en escenarios donde la dirección base no se puede determinar durante la construcción.
En general, Vite 3.0 trae algunos cambios arquitectónicos relativamente grandes, como confiar en la refactorización preconstruida, admitir el entorno de producción Esbuild, dependencias preempaquetadas y admitir completamente Pure ESM. Por supuesto, también hay algunos cambios de interrupción relativamente pequeños en esta versión. establecer versiones, como cambios en la sintaxis import.meta.glob.