Inconsistencias de webpack-dev-server al migrar de la versión 3 a la versión 4
Después de actualizar webpack-dev-server
de la versión 3 a la versión 4, encontré dos inconsistencias extrañas.
- El atributo
publicPath
de webpack-dev-server ya no funciona sin emparejarlo con la nueva opción static.- Antes, esto era suficiente para que funcionara:
js
{
// ...
devServer: {
publicPath: '/'
}
}
- Pero ahora se requiere lo siguiente en su lugar:
js
{
// ...
devServer: {
devMiddleware: {
publicPath: '/'
},
static: [
{
directory: context.replace(/\//g, '\\'),
publicPath: '/'
}
]
}
}
- Antes, esto era suficiente para que funcionara:
- El segundo problema también es visible en el código anterior. Puedes ver en la nueva versión de arriba que mi
context
tiene un truco extraño: tengo que reemplazar las barras diagonales hacia adelante por barras diagonales hacia atrás en Windows –context.replace(/\//g, '\\')
. Si no hago eso, soy castigado por un algoritmo de detección deURL
inexacto. Dado que las barras diagonales hacia adelante son perfectamente válidas en Windows, no debería quejarse de que no sea un directorio. Las propias herramientas de Windows piensan que es un directorio, perowebpack-dev-server
no lo hace:
Error: Utilizar una URL como static.directory no es compatible
at getStaticItem (c:\thecode\node_modules\webpack-dev-server\lib\Server.js:557:15)
at c:\thecode\node_modules\webpack-dev-server\lib\Server.js:1046:16
at Array.map (<anonymous>)
at Server.normalizeOptions (c:\thecode\node_modules\webpack-dev-server\lib\Server.js:1041:39)
at Server.start (c:\thecode\node_modules\webpack-dev-server\lib\Server.js:2252:16)
at Command.<anonymous> (c:\thecode\node_modules\@webpack-cli\serve\lib\index.js:242:38)
at async Promise.all (index 1)
at async Command.<anonymous> (c:\thecode\node_modules\webpack-cli\lib\webpack-cli.js:1672:7)
Mi configuración:
yaml
webpack: 5
OS: Windows 10
Node: 16
¿Estoy haciendo algo mal aquí? ¿Es este comportamiento documentado/esperado? ¿O debería informarlo en su página de problemas de Github?
Solución temporal para (2): el problema de la URL se puede solucionar mediante path.resolve
. Es decir: directory: path.resolve(context)
.
davy.ai
Inconsistencias extrañas encontradas después de actualizar
webpack-dev-server
de v3 a v4Como experto en IT especializado en javascript, webpack, migración y webpack-dev-server, me encontré con dos inconsistencias extrañas después de actualizar de
webpack-dev-server
v3 a v4.Inconsistencia #1
La primera inconsistencia está relacionada con la opción
publicPath
enwebpack-dev-server
. En la versión 3,publicPath
era suficiente para que todo funcionara de la siguiente manera:Sin embargo, en la versión 4, debe usarse junto con la nueva opción
static
, de la siguiente manera:Inconsistencia #2
La segunda inconsistencia es visible en el código anterior. El
context
tiene un truco extraño que reemplaza las barras diagonales con barras invertidas en Windows, como esto:context.replace(/\//g, '\\')
. Si no se utiliza este truco, se activa un algoritmo inexacto de detección deURL
. Esto no es un problema con las herramientas de Windows, ya que consideran las barras diagonales perfectamente aceptables. Sin embargo,webpack-dev-server
no lo hace y se muestra el siguiente error:Solución alternativa para la inconsistencia #2
Una solución alternativa para el problema de la URL en la inconsistencia #2 es corregirlo usando
path.resolve
. De la siguiente manera:directory: path.resolve(context)
.Conclusión
Estas inconsistencias se experimentaron en una configuración con
webpack
versión 5,Node
versión 16 y sistema operativoWindows 10
. Aunque estas inconsistencias pueden ser el resultado de un comportamiento esperado, puede ser necesario reportarlas en su página de problemas en Github para obtener una aclaración detallada.