css y build: preprocesadores, target, outDir y salida

Las claves css y build son donde la verdad de desarrollo se convierte en los bytes que sirves. css gobierna cómo Vite entiende tus estilos —preprocesadores como Sass, módulos con nombres locales, y en 2026 el motor Lightning CSS escrito en Rust— y build decide la forma del artefacto final: para qué navegadores compilas, dónde cae, cómo se parte y cuánto se minifica. Sobre Vite 8 con Rolldown, muchas de estas opciones estrenan motor pero conservan su nombre. Esta lección cierra el nivel con las palancas que realmente se ajustan y el criterio para no tocar las que no debes.

css: preprocesadores, modules y el motor

Vite entiende CSS de forma nativa, pero la clave css deja afinar tres cosas. preprocessorOptions pasa opciones a Sass, Less o Stylus: el uso más común es additionalData, que inyecta una cabecera —variables o mixins compartidos— en cada archivo sin que tengas que importarla a mano. Con Sass moderno conviene fijar la API nueva para evitar los avisos de deprecación del compilador antiguo.

import { defineConfig } from "vite"

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `@use "@/styles/vars.scss" as *;`,
        api: "modern-compiler",
      },
    },
    modules: {
      localsConvention: "camelCaseOnly",
      generateScopedName: "[name]__[local]___[hash:base64:5]",
    },
    devSourcemap: true,
  },
})

modules gobierna los CSS Modules, el mecanismo que aísla los nombres de clase por archivo para que dos componentes puedan usar .title sin pisarse. localsConvention decide cómo llegan esos nombres a tu JavaScript —camelCaseOnly convierte mi-clase en miClase— y generateScopedName controla el patrón del nombre único generado, útil para hacer legible el CSS en desarrollo y compacto en producción. devSourcemap te da mapas de origen del CSS en dev, para que el inspector señale tu archivo fuente y no el transformado.

El motor que procesa todo esto está cambiando. Durante años fue PostCSS; en 2026, con Vite volcado a herramientas en Rust, Lightning CSS gana terreno como transformador y minificador: hace el prefijado de vendedor, el downleveling de sintaxis moderna y la minificación en una sola pasada nativa, mucho más rápida. Se activa eligiéndolo como transformador, y entonces sustituye a la cadena de PostCSS.

export default defineConfig({
  css: {
    transformer: "lightningcss",
  },
  build: {
    cssMinify: "lightningcss",
  },
})

build: target, outDir y la forma de la salida

build describe el artefacto. La opción más consecuente es target: el nivel de sintaxis al que Vite rebaja tu código. Desde Vite 7 el valor por defecto es baseline-widely-available, que apunta a las capacidades soportadas de forma amplia y estable por los navegadores, un objetivo móvil que se actualiza con el consenso de la plataforma en lugar de fijar versiones a mano. Bajarlo compila para navegadores más antiguos a costa de más código y menos velocidad; subirlo produce bundles más pequeños que exigen navegadores recientes.

export default defineConfig({
  build: {
    target: "baseline-widely-available",
    outDir: "dist",
    assetsDir: "assets",
    sourcemap: true,
    cssCodeSplit: true,
    minify: "esbuild",
    emptyOutDir: true,
    chunkSizeWarningLimit: 600,
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ["react", "react-dom"],
        },
      },
    },
  },
})

outDir es la carpeta de salida —dist por defecto— y assetsDir la subcarpeta de recursos con hash dentro de ella. emptyOutDir limpia esa carpeta antes de cada build para que no queden restos de una compilación previa. sourcemap decide si emites mapas de origen para depurar producción, y cssCodeSplit mantiene el CSS partido por chunk en vez de un único archivo monolítico, de modo que cada ruta cargue solo su estilo.

flowchart LR
A[codigo fuente] --> B[transform de css y ts]
B --> C[rolldown empaqueta el grafo]
C --> D[minify y downlevel al target]
D --> E[archivos con hash en outDir]
E --> F[index.html apunta a los assets]
style D fill:#a6e3a1,color:#11111b

Las opciones que de verdad se tocan

En el día a día, tres palancas concentran casi todos los ajustes. minify elige minificador: el built-in rápido por defecto, o terser cuando necesitas su compresión más agresiva en casos límite, asumiendo que es más lento. manualChunks, dentro de rollupOptions, separa dependencias estables —tu framework— en un chunk propio que el navegador cachea entre despliegues, en vez de reempaquetarlo con tu código que cambia a diario. Y chunkSizeWarningLimit calla o endurece el aviso de chunk grande según lo que tu proyecto considere razonable.

Dos opciones más aparecen en cuanto integras el build con un backend. manifest emite un manifest.json que mapea cada entrada a su archivo con hash, para que un servidor —Rails, Django, Laravel— sepa qué script y qué link inyectar en su plantilla en lugar de adivinar nombres con hash. modulePreload gobierna las etiquetas de precarga que Vite añade para adelantar la descarga de los chunks que sabes que harán falta, recortando cascadas de red en la primera carga.

build: {
  manifest: true,
  assetsInlineLimit: 4096,
  reportCompressedSize: false,
}

assetsInlineLimit decide el umbral por debajo del cual Vite incrusta un recurso como data URI en lugar de emitir un archivo aparte: ahorra una petición a costa de algo de peso en el documento. sourcemap, por su parte, merece una decisión consciente en producción: emitirlos y servirlos expone tu código fuente a cualquiera, y no emitirlos deja tus reportes de error como pilas de líneas minificadas ilegibles. El punto intermedio habitual es generarlos pero no publicarlos, subiéndolos solo a tu plataforma de seguimiento de errores, que los usa para desminificar los stack traces sin que el mapa llegue al navegador de nadie.