webpack-dev-server: ReactJS dev server crashing after upgrade from 3.10.3 to 3.11.0
- Operating System: macOs 10.14.6
- Node Version: v12.13.0
- NPM Version: 6.12.0
- webpack Version: 4.43.0
- webpack-dev-server Version: 3.11.0
- Browser: Opera Developer Version:70.0.3693.0 / Chrome Version 81.0.4044.138 (Official Build) (64-bit) / Safari Version 13.1 (14609.1.20.111.8)
- This is a bug
- This is a modification request
Code
// webpack.config.js
'use strict'
const path = require('path')
const webpack = require('webpack')
const HtmlWebpackPlugin = require('html-webpack-plugin')
const CaseSensitivePathsPlugin = require('case-sensitive-paths-webpack-plugin')
const InterpolateHtmlPlugin = require('react-dev-utils/InterpolateHtmlPlugin')
const StyleLintPlugin = require('stylelint-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const getClientEnvironment = require('./env')
const paths = require('./paths')
const { getDevAssetPathPlugin } = require('../assets-path-compatibility')
const publicPath = '/'
const publicUrl = ''
const env = getClientEnvironment(publicUrl)
module.exports = {
mode: 'development',
devtool: 'cheap-module-source-map',
entry: [
'@babel/polyfill',
require.resolve('./dom-polyfill'),
require.resolve('react-dev-utils/webpackHotDevClient'),
paths.appIndexJs
],
output: {
pathinfo: true,
filename: 'static/js/bundle.js',
chunkFilename: 'static/js/[name].chunk.js',
publicPath: publicPath,
devtoolModuleFilenameTemplate: info =>
path.resolve(info.absoluteResourcePath).replace(/\\/g, '/')
},
resolve: {
modules: ['node_modules', paths.appNodeModules].concat(
process.env.NODE_PATH.split(path.delimiter).filter(Boolean)
),
extensions: [ /* ... */ ],
alias: { /* ... */ }
},
module: {
strictExportPresence: true,
rules: [
{
oneOf: [
{
test: /\.(js|jsx|ts|tsx|mjs)$/,
exclude: /(node_modules)/,
use: {
loader: 'babel-loader'
}
},
{
test: /\.css$/,
use: [
{
loader: 'style-loader'
},
MiniCssExtractPlugin.loader,
{
loader: 'css-loader',
options: {
sourceMap: true
}
},
{
loader: 'postcss-loader',
options: {
config: {
path: /* ... */
},
sourceMap: true
}
}
]
},
{
test: /\.scss$/,
loader: 'sass-extract-loader',
options: {
plugins: ['compact']
},
include: [ /* ... */ ]
},
{
test: /\.scss$/,
use: [
{
loader: 'style-loader'
},
{
loader: 'css-loader',
options: {
sourceMap: true
}
},
{
loader: 'postcss-loader',
options: {
config: {
path: /* ... */
},
sourceMap: true
}
},
{
loader: 'sass-loader',
options: {
sassOptions: {
includePaths: [ /* ... */ ],
outputStyle: 'expanded'
},
sourceMap: true
}
}
]
},
{
test: [/\.bmp$/, /\.gif$/, /\.jpe?g$/, /\.png$/],
use: [
{
loader: 'url-loader',
options: {
limit: 10000,
name: '/* ... */[name].[hash:8].[ext]'
}
}
]
},
{
test: /\.svg$/,
loader: 'raw-loader',
include: [ /* ... */ ]
},
{
test: /\.md$/,
use: [
{
loader: 'html-loader'
},
{
loader: 'markdown-loader'
}
]
},
{
exclude: [/\.js$/, /\.html$/, /\.json$/, /\.scss/],
loader: 'file-loader',
options: { /* ... */ }
}
]
}
]
},
plugins: [
new HtmlWebpackPlugin({
inject: true,
template: /* ... */
}),
new InterpolateHtmlPlugin(HtmlWebpackPlugin, env.raw),
new webpack.DefinePlugin(env.stringified),
new webpack.HotModuleReplacementPlugin(),
new MiniCssExtractPlugin({
filename: '[name].css',
chunkFilename: '[id].css'
}),
new CaseSensitivePathsPlugin(),
new StyleLintPlugin(),
getDevAssetPathPlugin()
],
node: {
dgram: 'empty',
fs: 'empty',
net: 'empty',
tls: 'empty',
child_process: 'empty'
},
performance: {
hints: false
}
}
Expected Behavior
Server keeps up and running as it always does
Actual Behavior
After the upgrade of the library webpack-dev-server from 3.10.3 to 3.11.0 the server randomly crashes as soon as I reload it few times, with this error as output
Compiled successfully!
You can now view toolkit in the browser.
Local: http://localhost:3000/
On Your Network: http://192.168.178.45:3000/
Note that the development build is not optimized.
To create a production build, use yarn build.
events.js:187
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:201:27)
Emitted 'error' event on Socket instance at:
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
errno: 'ECONNRESET',
code: 'ECONNRESET',
syscall: 'read'
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
- it crashes when I give the command yarn start
- it crashes if I reload the page with CMD+R
- it crashes if I reload the page pressing enter of the URL of my localhost
For Bugs; How can we reproduce the behavior?
In my project, once the server is launched the error appears after in the following scenario:
- doing nothing, means that as soon as server is up and running, the crash happens immediately
- I refresh the page of my local server with the buttons CMD+R
- I refresh the page of my local server pressing ENTER in the URL of my localhost
For Features; What is the motivation and/or use-case for the feature?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 19
- Comments: 28 (14 by maintainers)
Commits related to this issue
- Fixed ECONNRESET error upon client server bootup, issue here: https://github.com/webpack/webpack-dev-server/issues/2628#issuecomment-634475007 — committed to landon-himeda/AspNetCore-React-WebApp by deleted user 4 years ago
- Rename .env.development to .env, ECONNRESET webpack bugfix, jest and @testing-library/react config (#18) * Renamed client/.env.development to .env to prevent environment variable issues when deployin... — committed to microsoft/AspNetCore-React-WebApp by landon-himeda 4 years ago
- Rename .env.development to .env, ECONNRESET webpack bugfix, jest and @testing-library/react config (#18) * Renamed client/.env.development to .env to prevent environment variable issues when deployin... — committed to rexcare/scheduling by rexcare 4 years ago
- Rename .env.development to .env, ECONNRESET webpack bugfix, jest and @testing-library/react config (#18) * Renamed client/.env.development to .env to prevent environment variable issues when deployin... — committed to elliott717/web-api by elliott717 4 years ago
- Rename .env.development to .env, ECONNRESET webpack bugfix, jest and @testing-library/react config (#18) * Renamed client/.env.development to .env to prevent environment variable issues when deployin... — committed to apollon-comet/AspNetCore-React-WebApp by deleted user 4 years ago
- Rename .env.development to .env, ECONNRESET webpack bugfix, jest and @testing-library/react config (#18) * Renamed client/.env.development to .env to prevent environment variable issues when deployin... — committed to IlliaLysykh/ASP.Net-Core-React by IlliaLysykh 4 years ago
Unfortunately no progress on reproducing the error with a clean ejected CRA application. It seems like our ejection has moved too far away from the current CRA ejection. (Ieek!).
But anyway I was able to change the configuration for our code to get rid of the crashing.
In the
webpackDevServer.config.jsfile I addedto the configuration, which is also per default enabled in the latest CRA eject. This seems to solve the problems for all our repositories. (No errors so far today)
Yep, we have a lot of issue for webpack v5 😞 But now most of them resolved, so I can focus on webpack-dev-server fully
Anyway somebody can reproduce a problem? Will be great to fix it anyway 😄
I had this same problem with an ejected create-react-app project. The fix was to create a new project with the latest create-react-app and get the clean versions of the scripts/start.js file and the configuration files from the config directory. So for me it seemed to be just a matter of remembering to update the config files as well as the npm package in an ejected project.
If you want to take a look, the project that behaves exactly as described in the original post (3.11.0 package, 3.10.3 config): https://github.com/vorple/borogove-ide/tree/679be38db4887ec4e8464eb2e37153f1d5e8498d
Fixed after updating config files: https://github.com/vorple/borogove-ide/tree/1014e9063700cc5e5b4518f87fc364c5453f9ad6 (diff)
Yep, bug in
sockjs, and unfortunately we cannot fix it, anyway new version is usingwsby default, so no problems, for v3 you can use this workaround https://github.com/webpack/webpack-dev-server/issues/2628#issuecomment-634521675Ciao @evilebottnawi, we had the same problem upgrading from 3.10.3 to 3.11.0. The fix proposed by @lkloeppel seems to work! ❤️
It works also in my project. It seems it is something related to
sockjsupgrade that actually happened with the release webpackDevServer 3.11.0. Also confirmed by the resolution here => https://github.com/webpack/webpack-dev-server/issues/2628#issuecomment-633948254 Using ws instead of sockjs issue disappears as mentioned here => https://github.com/webpack/webpack-dev-server/issues/2628#issuecomment-634475007As a recap:
webpackDevServer 3.10.3 => sockjs 0.3.19 (2020-02-05) https://github.com/webpack/webpack-dev-server/releases/tag/v3.10.3
upgrade in package.json of sockjs (2020-03-18) https://github.com/webpack/webpack-dev-server/pull/2450/files
webpackDevServer 3.11.0 => sockjs 0.3.20 (2020-05-08) https://github.com/webpack/webpack-dev-server/releases/tag/v3.11.0
I would consider the issue closed. Thanks everyone for the support.
@silversonicaxel Maybe you can create private repo? If you need I can sign NDA
I must say, it is not triggered here the error, so the
console.log(error);command is not executed. Checking somewhere else in the file where the error could occur and eventually tell you the outcome.@silversonicaxel Do you use https? Very weird problem. Can you try add here https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L704:
@silversonicaxel Please try to do this, without this I will not be able to help and the issue will be closed after a while.
eh … I know you would have asked for it. Unluckily I’m not sure what I can do. The project has copyright on its core codebase so I can’t share the real repo, and it is not the smallest project ever. It might take a while to recreate a repo, hopefully with an error, cleaned from its private dependencies. I will investigate a bit more on what I could do. But I can’t promise anything.