webpack-dev-server Version: 3.3.1
[x] This is a bug
// webpack.config.js
const path = require("path");
module.exports = {
mode: 'development',
entry: './src/index.tsx',
output: {
path: path.resolve("..", "Web", "src", "DV.Adapters", "wwwroot"),
filename: "main.bundle.js"
},
devtool: "source-map",
resolve: {
extensions: [".ts", ".tsx", ".js", ".json", ".css"],
modules: [ path.resolve('./src/app'), path.resolve('node_modules') ]
},
module: {
rules: [
{ test: /\.tsx?$/, loader: "awesome-typescript-loader" },
{ enforce: "pre", test: /\.js$/, loader: "source-map-loader" },
]
}
};
// dev-server.js
const webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const config = require('./webpack.config');
const server = new WebpackDevServer(webpack(config), {
hot: true,
historyApiFallback: true,
publicPath: config.output.publicPath,
contentBase: "../DV.Adapters/",
proxy: {
"**": {
target: "http://localhost:5000",
logLevel: 'debug'
}
}
});
server.listen(3000, 'localhost', (err) => {
if (err) {
return console.log(err);
}
console.log('Listening at http://localhost:3000/');
});
Approximately same request time for every request to same ressource with same configuration.
Every second request takes significantly longer to connect as described in detail here: https://stackoverflow.com/questions/56007790/why-is-chrome-waiting-before-every-second-request-when-using-webpack-dev-server
I'm working on that. I will return and update this issue if I am able to make a simple repro.
Not sure it is related to dev server, problem in proxy, we don't use here any extra logic https://github.com/webpack/webpack-dev-server/blob/master/lib/Server.js#L386, also as you describe it is happens only in chrome, so please check your application on extra logic for chrome
Anyway feel free to put here reproducible test repo, maybe i can help you
@evilebottnawi thanks you for the fast reply! I've managed to work out a repro:
https://gist.github.com/asgerhallas/a92584cab937e11eabf93987497c0861
Be aware that the pattern sometimes only starts after request number two.
Is this usable?
@asgerhallas thanks, investigate
@asgerhallas can't reproduce, all work fine and no delay, i think you have chrome extension which causes this problem. Try to use incognito mode.
My Chrome: Version 74.0.3729.108 (Official Build) (64-bit)
@evilebottnawi thanks for trying it out! I will try in incognito - and let my coworkers try it out too - and report back.
I have the exact same pattern in incognito mode. My Chrome is: Version 74.0.3729.131 (Officiel version) (64-bit).
Three other coworkers of mine all experience the same, using different versions of Chrome :'(
Wonder if something on our network can cause this, even though it localhost only...
Ok, a little breakthrough. If I connect to the test setup via 127.0.0.1:3000 instead of localhost:3000 (no changes to the test setup, just another url in the browser), then it does not delay.
Maybe something on os level
Yes, sounds probable... which OS were you using?
Ubuntu 19.04
Thanks for all the help. A summary of what seems to be the case right now, the pattern emerges when using:
Both in NodeJS 10 and NodeJS 12. Tested on multiple machines and with Chrome in incognito mode as well.
Should this be an issue here https://github.com/nodejitsu/node-http-proxy or here https://github.com/chimurai/http-proxy-middleware maybe?
Not sure, problem on os or network side, maybe in software on your computer, node-http-proxy and http-proxy-middleware uses in production on many servers. But if it is reproduce only on chrome, maybe problem in chrome, devtool often give extra load on browser.
@asgerhallas
Can you try to replace localhost by 127.0.0.1?
I think the proxy is resolving localhost using ipv6 (::1:) so your connections will be stalled.
Seems that the proxy donot work well using ipv6 in windows 10
@jmesa-sistel That's interesting! Do you mean make the proxy target 127.0.0.1? I'll try that right away.
Accessing the dev-server through 127.0.0.1:3000 makes the problem go away - but I don't understand how that'll affect the proxy?
@asgerhallas I think it's related how the proxy is resolving localhost in Windows 10.
I have had the same problem.
If you do a ping to localhost you will see ::1: instead 127.0.0.1
Another test is disable ipv6 in the network interface of your adapter and use localhost.
If works that's means that the proxy is resolving localhost using windows 10 preference.
In think the ideal solution is an option to choose ip version in proxy, so the proxy will force to resolve names using the selected ip version or force ipv4 when using localhost.
@evilebottnawi What do you think?
@jmesa-sistel thanks for the elaboration. You're right that my ping to localhost shows ::1 on my computer. What I can't understand (probably due to my ignorance about networking) is why it is the address I enter in the browser to access the dev-server that makes the difference?
Chrome address dev-server-url proxy target-url result
localhost:3000 localhost:3000 localhost:3001 delay
localhost:3000 127.0.0.1:3000 localhost:3001 delay
localhost:3000 127.0.0.1:3000 127.0.0.1:3001 delay
127.0.0.1:3000 localhost:3000 localhost:3001 **no delay**
And then again, if I go to localhost:3001 directly => no delay either?
@asgerhallas Sorry but I am not an expert, maybe @evilebottnawi knows the reason.
I gues that we have mixed conections some on ipv6 and others in ipv4.
I theory all using localhost should work but I guess that dev-server use ipv4 on localhost, but I am not sure at all.
@asgerhallas
I have try in Chrome http://[::1]:3000 and it is not working for me, so I guess it's because dev-server is using ipv4 on localhost
Probably if you open devserver using :: then it will work
server.listen(3000, '::1', (err) => {
If you confirm that works using the previous code, then devserver resolve localhost to a ipv4 and it is not using windows to resolve the host name
@asgerhallas @evilebottnawi I have been doing some tests in Windows 10.
devserver --host :: -> chrome http://localhost works
devserver --host ::1 -> chrome http://localhost works
devserver --host 0.0.0.0 -> chrome http://localhost delay
devserver --host localhost -> chrome http://localhost delay
Then I think the problem is that devserver is not using the OS to resolve localhost, seems that localhost is like an alias to 127.0.0.1
@jmesa-sistel Sorry for the delay, was not home during the weekend. This is very interresting! And actually provides a solution too - for my concrete problem at least.
So does this mean that when using IPv6 localhost to connect to a server listening on IPv4 localhost it will delay every second time? I wonder why that is though :)
@asgerhallas The delay is the time to resolve localhost to a valid ip, you can see it in chrome devtools in network, I think the delay problem is in devserver when a proxy is used only, but I am not a expert so I'm guessing. I change my config to use ipv4 (127.0.0.1) instead localhost, so everything is fine for me, but I guess a lot of people will have similar problems using proxy and localhost.
@jmesa-sistel but isn't it strange that this delay only occurs every second request?
@jmesa-sistel just wanted to check back in and say that thanks a lot for solving my problem! Thanks :)
So the problem is with the webpack dev server? Or is this a windows issue?
I've been having this problem for years now, across tons of projects and windows dev boxes.
Most helpful comment
@asgerhallas The delay is the time to resolve localhost to a valid ip, you can see it in chrome devtools in network, I think the delay problem is in devserver when a proxy is used only, but I am not a expert so I'm guessing. I change my config to use ipv4 (127.0.0.1) instead localhost, so everything is fine for me, but I guess a lot of people will have similar problems using proxy and localhost.