Opciones para server
server.host
Tipo:
string | boolean
Por defecto:
'localhost'
Especifica en qué direcciones IP debe escuchar el servidor. Configuralo en
0.0.0.0
otrue
para escuchar en todas las direcciones, incluidas las LAN y las direcciones públicas.Esto se puede configurar a través de la CLI usando
--host 0.0.0.0
o--host
.NOTA
Hay casos en los que otros servidores pueden responder en lugar de Vite.
El primer caso es cuando se usa
localhost
. Node.js bajo v17 reordena el resultado de la dirección resuelta por DNS de forma predeterminada. Al acceder alocalhost
, los navegadores usan DNS para resolver la dirección y esa dirección puede diferir de la dirección que está escuchando Vite. Vite imprime en consola la dirección resuelta cuando difiere.Puedes configurar
dns.setDefaultResultOrder('verbatim')
para deshabilitar el comportamiento de reordenación. Vite luego imprimirá la dirección comolocalhost
.vite.config.jsjsimport {
defineConfig} from 'vite' importdnsfrom 'node:dns'dns.setDefaultResultOrder('verbatim') export defaultdefineConfig({ // omitido })El segundo caso es cuando se utilizan hosts comodín (por ejemplo,
0.0.0.0
). Esto se debe a que los servidores que escuchan en hosts que no son comodín tienen prioridad sobre los que escuchan en hosts comodín.::: Consejo: Acceder al servidor en WSL2 desde tu LAN
Cuando ejecutas Vite en WSL2, no es suficiente configurar host: true
para acceder al servidor desde tu LAN. Consulta el documento de WSL para más detalles.
:::
server.port
Tipo:
number
Por defecto:
5173
Especifica el puerto del servidor. Ten en cuenta que si el puerto ya se está utilizando, Vite probará automáticamente el siguiente puerto disponible, por lo que es posible que este no sea el puerto real en el que el servidor terminará escuchando.
server.strictPort
Tipo:
boolean
Colocalo en
true
para finalizar si el puerto ya está en uso, en lugar de probar automáticamente el siguiente puerto disponible.
server.https
Tipo:
https.ServerOptions
Habilita TLS + HTTP/2. Ten en cuenta que esto cambia a TLS solo cuando también se usa la opción
server.proxy
.El valor también puede ser un objeto de opciones pasado a
https.createServer()
.Se necesita un certificado válido. Para una configuración básica, puedes agregar @vite/plugin-basic-ssl a los plugins del proyecto, que crearán y almacenarán automáticamente un certificado autofirmado. Pero recomendamos crear tus propios certificados.
server.open
Tipo:
boolean | string
Abre automáticamente la aplicación en el navegador al iniciar el servidor. Cuando el valor es una cadena, se utilizará como nombre de ruta de la URL. Si deseas abrir el servidor en un navegador específico, puedes configurar
process.env.BROWSER
(por ejemplo,firefox
). También puedes configurarprocess.env.BROWSER_ARGS
para pasar argumentos adicionales (por ejemplo,--incognito
).BROWSER
yBROWSER_ARGS
también son variables de entorno especiales que puedes colocar en el archivo.env
para configurarlo. Consulta el paqueteopen
para obtener más detalles.Ejemplo:
jsexport default defineConfig({ server: { open: '/docs/index.html', }, })
server.proxy
Tipo:
Record<string, string | ProxyOptions>
Configura reglas de proxy personalizadas para el servidor de desarrollo. Espera un objeto de pares
{ key: options }
. Cualquier solicitud cuya ruta de solicitud comience con esa clave se enviará a ese destino especificado. Si la clave comienza con^
, se interpretará comoRegExp
. La opciónconfigure
se puede utilizar para acceder a la instancia del proxy.Ten en cuenta que si estás utilizando una
base
no relativa, debes prefijar cada clave con esabase
.Extiende
http-proxy
. Las opciones adicionales están aquí.En algunos casos, es posible que también desees configurar el servidor de desarrollo relacionado (por ejemplo, para agregar middlewares personalizados a la aplicación interna connect). Para hacerlo, debes escribir tu propio plugin y usar la función configureServer.
Ejemplo:
jsexport default defineConfig({ server: { proxy: { // string shorthand '/foo': 'http://localhost:4567', // con opciones '/api': { target: 'http://jsonplaceholder.typicode.com', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, ''), }, // con RegExp '^/fallback/.*': { target: 'http://jsonplaceholder.typicode.com', changeOrigin: true, rewrite: (path) => path.replace(/^\/fallback/, ''), }, // Usando la instancia de proxy '/api': { target: 'http://jsonplaceholder.typicode.com', changeOrigin: true, configure: (proxy, options) => { // proxy será una instancia de 'http-proxy' }, }, // Haciendo proxy de websockets o socket.io: ws://localhost:5173/socket.io -> ws://localhost:5174/socket.io // Ten precaución al usar `rewriteWsOrigin`, ya que puede dejar el proxy abierto a ataques CSRF. '/socket.io': { target: 'ws://localhost:5173', ws: true, rewriteWsOrigin: true, }, }, }, })
server.cors
Tipo:
boolean | CorsOptions
Configura las CORS para el servidor de desarrollo. Esto está habilitado por defecto y permite cualquier origen. Pase un objeto de opciones para ajustar el comportamiento o
false
para deshabilitarlo.
server.headers
Tipo:
OutgoingHttpHeaders
Especifica los encabezados de respuesta del servidor.
server.hmr
- Tipo:
boolean | { protocol?: string, host?: string, port?: number, path?: string, timeout?: number, overlay?: boolean, clientPort?: number, server?: Server }
Deshabilita o configura la conexión HMR (en los casos en que el websocket HMR deba usar una dirección diferente del servidor http).
Coloca server.hmr.overlay
en false
para deshabilitar la superposición de errores del servidor.
protocol
establece el protocolo WebSocket utilizado para la conexión HMR: ws
(WebSocket) o wss
(WebSocket Seguro).
clientPort
es una opción avanzada que sobreescribe el puerto solo en el lado del cliente, lo que le permite servir el websocket en un puerto diferente al que busca el código del cliente.
Cuando se define server.hmr.server
, Vite procesará las solicitudes de conexión HMR a través del servidor provisto. Si no está en modo middleware, Vite intentará procesar las solicitudes de conexión HMR a través del servidor existente. Esto puede ser útil cuando se usan certificados autofirmados o cuando desea exponer a Vite a través de una red en un solo puerto.
Consulta vite-setup-catalogue
para ver algunos ejemplos.
NOTA
Con la configuración predeterminada, se espera que los proxies inversos frente a Vite admitan WebSocket de proxy. Si el cliente de Vite HMR no logra conectar WebSocket, el cliente recurrirá a conectar WebSocket directamente al servidor de Vite HMR sin pasar por los proxies inversos:
Direct websocket connection fallback. Check out https://vite.dev/config/server-options.html#server-hmr to remove the previous connection error.
Se puede ignorar el error que aparece en el navegador cuando ocurre el fallback. Para evitar el error al omitir directamente los proxies inversos, podrías:
- configurar el proxy inverso para el proxy de WebSocket también
- configurar
server.strictPort = true
y configurarserver.hmr.clientPort
con el mismo valor queserver.port
- configurar
server.hmr.port
en un valor diferente deserver.port
server.warmup
- Tipo:
{ clientFiles?: string[], ssrFiles?: string[] }
- Relacionado: Preparación de archivos de uso frecuente
Prepara archivos para transformarlos y almacenar en caché los resultados por adelantado. Esto mejora la carga de la página inicial durante el inicio del servidor y evita transformaciones en cascada.
clientFiles
son archivos que se usan solo en el cliente, mientras que ssrFiles
son archivos que se usan solo en SSR. Aceptan una variedad de rutas de archivos o patrones fast-glob
relativos a root
.
Asegúrate de agregar solo archivos que se usan con frecuencia para no sobrecargar el servidor de desarrollo de Vite al iniciar.
export defineConfig default ({
server: {
warmup: {
clientFiles: ['./src/components/*.vue', './src/utils/big-utils.js'],
ssrFiles: ['./src/server/modules/*.js'],
},
},
})
server.watch
- Tipo:
object | null
Opciones para el observador del sistema de archivos que serán pasados a chokidar.
El observador del servidor Vite observa el root
y omite los directorios .git/
, node_modules/
, y las carpetas de Vite cacheDir
y build.outDir
de forma predeterminada. Al actualizar un archivo observado, Vite aplicará HMR y actualizará la página solo si es necesario.
Si se configura en null
, no se observará ningún archivo. server.watcher
proporcionará un emisor de eventos compatible, pero invocar a add
o unwatch
no tendrá ningún efecto.
Observando archivos en node_modules
Actualmente no es posible ver archivos y paquetes en node_modules
. Para obtener más avances y soluciones alternativas, puede seguir la propuesta #8619.
Uso de Vite en el Subsistema de Windows para Linux (WSL) 2
Al ejecutar Vite en WSL2, la observación del sistema de archivos no funciona cuando un archivo es editado por aplicaciones de Windows (procesos no-WSL2). Esto se debe a una limitación de WSL2. Esto también se aplica a la ejecución en Docker con un backend de WSL2.
Para solucionarlo, podrías:
- Recomendado: Utilizar las aplicaciones WSL2 para editar tus archivos.
- También se recomienda mover la carpeta del proyecto fuera del sistema de archivos de Windows. El acceso al sistema de archivos de Windows desde WSL2 es lento. Eliminar esa sobrecarga mejorará el rendimiento.
- Configura
{ usePolling: true }
.- Ten en cuenta que
usePolling
conduce a un uso elevado de la CPU.
- Ten en cuenta que
server.middlewareMode
Tipo:
boolean
Por defecto:
false
Crea un servidor Vite en modo middleware.
Relacionado: appType, SSR - Configuración del servidor de desarrollo
Ejemplo:
import express from 'express'
import { createServer as createViteServer } from 'vite'
async function createServer() {
const app = express()
// Crea servidor Vite en modo middleware
const vite = await createViteServer({
server: { middlewareMode: true },
appType: 'custom' // no incluir middlewares de manejo de HTML predeterminado de Vite
// Usa la instancia de conexión de vite como middleware
app.use(vite.middlewares)
app.use('*', async (req, res) => {
// Dado que `appType` es `'custom'`, debería servir la respuesta aquí.
// Nota: si `appType` es `'spa'` o `'mpa'`, Vite incluye middlewares para manejar
// Solicitudes HTML y 404, por lo que se deben agregar middlewares de usuario
// antes de que los middlewares de Vite surtan efecto en su lugar
})
}
createServer()
server.fs.strict
Tipo:
boolean
Por defecto:
true
(habilitado por defecto desde Vite 2.7)Restringe el servicio de archivos fuera de la raíz del espacio de trabajo.
server.fs.allow
Tipo:
string[]
Restringe los archivos que podrían servirse a través de
/@fs/
. Cuandoserver.fs.strict
se coloca entrue
, el acceso a archivos fuera de esta lista de directorios que no se importaron de un archivo permitido resultará en un 403.Se pueden proporcionar tanto directorios como archivos.
Vite buscará la raíz del potencial espacio de trabajo y la usará por defecto. Un espacio de trabajo válido cumple con las siguientes condiciones; de lo contrario, se recurrirá a la raíz del proyecto.
- contiene el campo
workspaces
enpackage.json
- contiene uno de los siguientes archivos
pnpm-workspace.yaml
Acepta una ruta para especificar la raíz del espacio de trabajo personalizado. Podría ser una ruta absoluta o una ruta relativa a la raíz del proyecto. Por ejemplo:
jsexport default defineConfig({ server: { fs: { // Permitir servir archivos desde un nivel hasta la raíz del proyecto allow: ['..'], }, }, })
Cuando se especifica
server.fs.allow
, la detección automática de la raíz del espacio de trabajo se desactivará. Para ampliar el comportamiento original, se expone una utilidadsearchForWorkspaceRoot
:jsimport { defineConfig, searchForWorkspaceRoot } from 'vite' export default defineConfig({ server: { fs: { allow: [ // busca la raíz del espacio de trabajo searchForWorkspaceRoot(process.cwd()), // tus reglas personalizadas '/path/to/custom/allow_directory', '/path/to/custom/allow_file.demo', ], }, }, })
- contiene el campo
server.fs.deny
Tipo:
string[]
Por defecto:
['.env', '.env.*', '*.{crt,pem}']
Lista de bloqueo para archivos sensibles que están restringidos para ser servidos por el servidor de desarrollo de Vite. Esto tendrá mayor prioridad que
server.fs.allow
. Se admiten patrones de picomatch.
server.fs.cachedChecks
- Tipo:
boolean
- Por defecto:
false
- Experimental
Cachea los nombres de archivo de los directorios accedidos para evitar operaciones repetidas del sistema de archivos. Especialmente en Windows, esto podría resultar en una mejora de rendimiento. Está desactivado por defecto debido a casos límite al escribir un archivo en una carpeta en caché e importarlo inmediatamente.
server.origin
Tipo:
string
Define el origen de las URL de recursos generadas durante el desarrollo.
jsexport default defineConfig({ server: { origin: 'http://127.0.0.1:8080', }, })
server.sourcemapIgnoreList
- Tipo:
false | (sourcePath: string, sourcemapPath: string) => boolean
- Por defecto:
(sourcePath) => sourcePath.includes('node_modules')
Permite configurar si se ignoran o no los archivos de origen en el mapa de origen del servidor, que se usan para completar la extensión del mapa de origen de x_google_ignoreList
.
server.sourcemapIgnoreList
es el equivalente de build.rollupOptions.output.sourcemapIgnoreList
para el servidor de desarrollo. Una diferencia entre las dos opciones de configuración es que la función de Rollup se invoca con una ruta relativa para sourcePath
mientras que server.sourcemapIgnoreList
lo hace con una ruta absoluta. Durante el desarrollo, la mayoría de los módulos tienen el mapa y la fuente en la misma carpeta, por lo que la ruta relativa para sourcePath
es el nombre del archivo en sí. En estos casos, las rutas absolutas se hacen convenientes para su uso.
Por defecto, se excluyen todas las rutas que contienen node_modules
. Puedes pasar false
para deshabilitar este comportamiento o, para un control total, una función que toma la ruta de origen y la ruta del mapa de origen y devuelve si se ignora la ruta de origen.
export default defineConfig({
server: {
// Este es el valor predeterminado y agregará todos los archivos
// con node_modules en sus rutas a la lista de ignorados.
sourcemapIgnoreList(sourcePath, sourcemapPath) {
return sourcePath.includes('node_modules')
},
},
})
Nota
server.sourcemapIgnoreList
y build.rollupOptions.output.sourcemapIgnoreList
necesitan ser configurados independientemente. server.sourcemapIgnoreList
es únicamente una configuración de servidor y no obtiene su valor por defecto de las opciones definidas de Rollup.