Webpack crea un servidor de desarrollo local

Esta configuración previa del paquete web es esencial. Sin embargo, la experiencia de desarrollo no es buena y se ha requerido npm run build para empaquetar manualmente.

Esperamos que cuando el archivo cambie, la compilación y la visualización se puedan completar automáticamente;
para completar la compilación automática, webpack proporciona varios métodos opcionales:

• modo de reloj webpack;
• webpack-dev-server (comúnmente utilizado);
• webpack-dev-middleware;

reloj paquete web

webpack nos proporciona el modo reloj.
En este modo, todos los archivos en el gráfico de dependencia del paquete web, siempre que uno de ellos esté actualizado, el código se volverá a compilar;
no necesitamos ejecutar manualmente el comando npm run build.
Nota: solo se compilará y empaquetará automáticamente. Para verlo en tiempo real en el navegador, debe cooperar con el servidor en vivo para abrir el html.

¿Cómo encender el reloj? Dos caminos:

• Método 1: en el archivo de configuración exportado, es decir, agregue webpack.config.jswatch: true;
• Método 2: en el comando para iniciar el paquete web, agregue --watchel logotipo;

Podemos agregar indicadores a los scripts npm, porque los scripts en los scripts en realidad usan npm run para ayudarlo a ejecutar los siguientes comandos en la línea de comandos. Lo mismo es cierto para el paquete web aquí. La ejecución en la línea de comando depende esencialmente de webpack-cli, incluida la configuración del atributo --watch que cli también agrega al archivo de configuración.

{
    
    
  "scripts": {
    
    
    "build": "webpack --watch"
  },
}

webpack-dev-servidor

Si queremos implementar la recarga en vivo (recarga en tiempo real) sin usar el servidor en vivo, podemos usar webpack-dev-server.
Iniciará un servidor rápido, por lo que cuando se abra el navegador, primero descargará index.html y luego descargará otros archivos de index.html, al igual que abrir un sitio web general.

De hecho, webpack-dev-server no escribe ningún archivo de salida después de la compilación. En su lugar, mantenga el archivo del paquete en la memoria

Instalar:npm i webpack-dev-server -D

Uso: webpack servesolo inícielo, por lo general también lo usamos en el script npm
"serve": "webpack serve --config webpack.config.js"
paste&height=142&id=u3e7b03df&name=image.png&originHeight=222&originWidth=1055&originalType=binary&ratio=1&rotation=0&showTitle=false&size=42403&status=error&style=none&taskId=ud0771a41 -16ac -4b79- bfad-aaff037763f&title=&ancho=675.2)

La ruta donde el servicio webpack-dev-server busca archivos es:

• http://[devServer.host]:[devServer.port]/[output.publicPath]/[output.filename]

output: {
    
    
  filename: "js/bundle.js",
  path: path.resolve(__dirname, "./dist"),
  publicPath: "hhh"
}

El host y el puerto predeterminados son localhost: 8080. Si la salida está configurada como se indica arriba, la URL para solicitar js es

• http://127.0.0.1:8080/hhh/js/bundle.js

configuración del paquete web: devServer

Si queremos configurar el servidor de desarrollo local, podemos devServerconfigurarlo en las opciones de nivel superior del objeto de configuración de wepback. Eso sí, muchos de ellos ya vienen configurados por defecto.

Además, se puede agregar un objetivo de opción de nivel superior para identificar el entorno de uso del producto empaquetado.target: "web"|"node"

estático

Se pueden configurar muchas propiedades en devServer, contentBase es una de ellas.
contentBase: indica que el servidor de desarrollo le dirá al navegador en qué directorio se encuentran los archivos que no están empaquetados por webpack, de modo que el navegador pueda ir directamente a ese directorio para obtener los archivos en lugar de descargarlos en el paquete empaquetado.
Por ejemplo, favorite.ico, el entorno de producción debe copiarse en la carpeta empaquetada, pero no es necesario copiar la etapa de desarrollo, por lo que puede especificar ./public como base de contenido para facilitar que el navegador cargue el ícono.
Algunos archivos adicionales son muy grandes, por lo que no es necesario empaquetarlos, lo que mejora la eficiencia del desarrollo y el empaquetado.
Sin embargo, ha quedado en desuso.

Todas las opciones que puede configurar devServer se han marcado en la información de solicitud y, por supuesto, muchas opciones tienen configuraciones predeterminadas.

Ahora, si desea lograr el mismo efecto que la base de contenido anterior, debe usar staticlas opciones para especificar el directorio de archivos estáticos. Los archivos en el directorio equivalen a agregarse al directorio de exportación empaquetado.

module.exports = {
    
    
  devServer: {
    
    
    static: "./img"
  }
}

<img src="./1.png" alt="">

Abra el navegador para ver y encontrará que la imagen 1.png está vinculada a la carpeta img local y no ha sido empaquetada.

anfitrión

host establece la dirección del host:

• El valor predeterminado es localhost;
• Si desea ser accesible desde otros lugares, puede establecerlo en 0.0.0.0;

La diferencia entre localhost y 0.0.0.0:

• localhost: esencialmente un nombre de dominio, generalmente resuelto en 127.0.0.1;
• 127.0.0.1: Loop Back Address (Loop Back Address), lo que significa que los paquetes enviados por nuestro host son recibidos directamente por nosotros mismos;

La ruta normal de envío de paquetes de base de datos es la capa de aplicación-capa de transporte-capa de red-capa de enlace de datos-capa física; la
dirección de bucle invertido se obtiene directamente en la capa de red y no irá a la capa de enlace de datos ni a la capa física
; si alguien más inicia el servidor local en el host bajo el mismo segmento de red, no podemos acceder al servidor de otras personas a través de 127.0.0.1. Debido a que la tarjeta de red no enviará la solicitud, es por eso que 127.0.0.1 se denomina host local.

0.0.0.0: Escuche todas las direcciones en IPV4 y luego encuentre diferentes aplicaciones según el puerto,
por ejemplo, si abrimos el servicio de 0.0.0.0, en los hosts bajo el mismo segmento de red, otros pueden acceder a mi servidor a través de 0.0 .0.0 . Debido a que es una dirección de transmisión, la solicitud se enviará a todos los hosts del segmento de red.

puerto、abierto、comprimir

puerto: configure el puerto de escucha, el valor predeterminado es 8080
abierto: si abrir el navegador:

• El valor predeterminado es falso, establecerlo en verdadero abrirá el navegador;
• También se puede establecer en un valor similar a Google Chrome;

compress Si habilitar la compresión gzip para archivos estáticos:

Nota: Algunos puertos están en la lista negra del navegador, por ejemplo: 6666. Estos puertos no se pueden configurar.

Reemplazo de módulo caliente (HMR)

¿Qué es HMR?

• El nombre completo de HMR es Reemplazo de módulo en caliente, traducido como reemplazo en caliente de módulo;
• El reemplazo en caliente del módulo se refiere a reemplazar, agregar y eliminar módulos durante la ejecución de la aplicación sin actualizar toda la página ;

HMR mejora la velocidad de desarrollo a través de los siguientes métodos:

• No recargue toda la página, lo que puede evitar que se pierda parte del estado de la aplicación;
• Solo actualice el contenido que necesita ser cambiado, ahorrando tiempo de desarrollo;
• Si modificas el código fuente de css y js, se actualizará en el navegador inmediatamente, lo que equivale a modificar directamente el estilo en las devtools del navegador;

¿Cómo usar HMR?
De forma predeterminada, webpack-dev-server ya es compatible con HMR y está activado de forma predeterminada;**devServer: { hot: true }**
si HMR no está activado, cuando modifiquemos el código fuente, toda la página se actualizará automáticamente, usando live reloading;

WDS: servidor de desarrollo webpack

Pero encontrará que cuando modificamos el código de un determinado módulo, toda la página aún se actualiza:
esto se debe a que necesitamos especificar qué módulos se actualizan para realizar HMR;

if (module.hot) {
    
    
  module.hot.accept("./js/element.js", () => {
    
    
    console.log("element模块发生更新了");
  })
}

Marco HMR

Hay una pregunta: al desarrollar otros proyectos, ¿a menudo necesitamos escribir manualmente las API relacionadas con module.hot.accpet?
Por ejemplo, en el desarrollo de proyectos de Vue y React, hemos modificado los componentes y esperamos realizar actualizaciones en caliente ¿Cómo debemos operar en este momento?

De hecho, la comunidad ya tiene soluciones muy maduras para esto:
por ejemplo, en el desarrollo de vue, usamos vue-loader, que admite el HMR de los componentes de vue y brinda una experiencia lista para usar; por ejemplo, en
react desarrollo, hay React Hot Loader, ajuste los componentes de reacción en tiempo real (actualmente React ha sido oficialmente obsoleto, use react-refresh en su lugar)

Principio de HMR

Entonces, ¿cuál es el principio de HMR? ¿Cómo puede ser posible actualizar solo el contenido en un módulo?

• webpack-dev-server creará dos servicios: un servicio que proporciona recursos estáticos (express) y un servicio Socket (net.Socket);
• El servidor express es responsable de proporcionar directamente servicios de recursos estáticos (el navegador solicita y analiza directamente los recursos empaquetados);

HMR Socket Server es una conexión de socket larga:

• Uno de los mejores beneficios de una conexión larga es que las dos partes pueden comunicarse después de establecer la conexión (el servidor puede enviar archivos directamente al cliente);
• Cuando el servidor detecta que el módulo correspondiente cambia, se generarán dos archivos, .json (archivo de manifiesto) y archivo .js (fragmento de actualización);
• A través de la conexión larga, estos dos archivos se pueden enviar directamente al cliente (navegador);
• Después de que el navegador obtiene los dos archivos nuevos, carga los dos archivos a través del mecanismo de tiempo de ejecución de HMR y actualiza los módulos modificados;

Apoderado

Proxy es una opción de configuración muy común en nuestro desarrollo, su finalidad es configurar un proxy para solucionar el problema del acceso entre dominios:

• Por ejemplo, una de nuestras solicitudes de API es http://192.163.0.66/12345, pero el nombre de dominio del servidor de inicio local es http://localhost: 8080. En este momento, el envío de solicitudes de red causará problemas entre dominios. ;
• Luego, podemos enviar primero la solicitud a un servidor proxy. El servidor proxy y el servidor API no tienen problemas entre dominios, por lo que podemos resolver nuestros problemas entre dominios.
• El servidor proxy iniciado por webpack es express

dominio cruzado

uso básico

Establezca un marcador de posición en devServer que reemplace la dirección del servidor de destino solicitada .
Por ejemplo, la fuente del servicio iniciada por el paquete web local es http://localhost/8080, y ahora desea solicitar la fuente de destino http://192.163.0.66:12345, la API es /get.

fetch("http://192.163.0.66:12345")
  .then(response => response.json())
  .then(result => console.log(result))

Obviamente, esto debe ocurrir entre dominios, porque los números de puerto son diferentes. En este momento, necesitamos usar un proxy. El método específico es permitir que el marcador de posición reemplace la fuente de destino:

fetch("/api/get") // ‘/api’ 为占位符
	.then(response => response.json())
  .then(result => console.log(result))

Pero ahora hay un problema, todavía no podemos solicitar los datos. Debido a que el marcador de posición no se eliminará, se agregará a la URL que realmente solicita los datos del servidor.

rutaReescribir

La arquitectura de solicitud actual es solicitud de navegador --> solicitud de servidor proxy --> servidor real.
Verificamos la URL del encabezado de la solicitud, y no ha habido http://localhost/8080/api/getdominios cruzados, pero la solicitud enviada por el servidor proxy al servidor real también tiene un marcador de posición/api, pero de hecho no hay un recurso correspondiente en el servidor real, por lo que devolverá 404 .
En este momento, es absolutamente necesario volver a escribir la URL de solicitud del servidor proxy y eliminar el marcador de posición. ****pathRewrite: { "^/api-hy": "" }**

cambio de origen

changeOrigin puede modificar el atributo de host en los encabezados de la solicitud de proxy y cambiarlo a la fuente de solicitud de destino correspondiente al destino.
El servidor proxy envía una solicitud al servidor real, porque el servidor no tiene una política del mismo origen, por lo que cualquier fuente de solicitud puede enviarla a voluntad. Por ejemplo, el servidor proxy iniciado por webpack es la fuente de la solicitud al servidor real http://localhost:3000.
Sin embargo, puede haber restricciones en el servidor real, como la prevención de rastreadores y similares. La URL del encabezado de la solicitud de verificación debe ser coherente con la fuente del servidor real. Luego puede establecer changeOrigin en verdadero para modificar. Como se muestra en la figura anterior.

Configuración general

Resumen:

• destino: indica la dirección de destino a la que se va a enviar el proxy,
• pathRewrite: reescritura de ruta.
• seguro: por defecto, el servidor que reenvía a https no se recibe, si desea admitirlo, puede configurarlo en falso;
• changeOrigin: Indica si actualizar la dirección del host en los encabezados solicitados por el proxy;

devServer: {
    
    
    proxy: {
    
    
      "/api-hy": {
    
     // 占位符
        target: "http://192.163.0.66/12345",
        pathRewrite: {
    
    
          "^/api-hy": ""
      	},
        secure: false,
        changeOrigin: true
      }
    }
  }
}

historyApiFallback

historyApiFallback es un atributo muy común en desarrollo, su principal función es solucionar el error de devolver 404 cuando la página SPA refresca la página después de los saltos de ruta .
Porque actualizar es enviar una solicitud al servidor con la url en la barra de direcciones, pero la ruta actual se establece en el extremo frontal de la página SPA, y el recurso correspondiente a la url del servidor será 404.

historyApiFallback tiene dos valores:

• valor booleano: el valor predeterminado es falso

Si se establece en verdadero, el contenido de index.html se devolverá automáticamente cuando se devuelva un error 404 durante la actualización;

• El valor del tipo de objeto puede configurar el atributo de reescrituras:

Puede configurar desde para que coincida con la ruta y decidir a qué página saltar;

De hecho, la función historyApiFallback en devServer se implementa a través de la biblioteca connect-history-api-fallback:
puede ver el documento connect-history-api-fallback