Closed vivmaha closed 7 years ago
yes, for this to work on a windows machine, this is critical.
Changes to the connect-livereload
package have moved hostname detection to the server, but this package still provides {hostname: options.hostname}
as an argument to the connect-livereload
middleware, which causes the hostname to always be 0.0.0.0
. How about removing that property and letting connect-livereload
figure out the hostname itself?
Is the issue that prompted that change still applicable? Should we have a different name for the livereload hostname configuration option?
Rather than specifying {livereload: true}
for this plugin's configuration, as a workaround you can add the middleware yourself and you should get the dynamic behavior:
options: {
middleware: function (connect, options, middlewares) {
middlewares.unshift(
require('connect-livereload')()
);
return middlewares;
}
}
I am now able to solve this by adding setting the hostname
option to localhost
.
connect: {
server: {
options: {
port: 9001,
base: './build',
livereload: true,
hostname:'localhost',
},
},
},
If you want to work with anoter device, in hostname
you should specify the network address (e.g. 192.168.0.101
).
Currently, 0.0.0.0 is used as the livereload host.
I'm using grunt-contrib-watch, which uses "localhost" instead of "0.0.0.0" for livereload.
I'd like to get grunt-contrib-connect to use "localhost" so that it will be compatible with grunt-contrib-watch.