Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Here's the error we were encountering when running mocha-chrome on Node >=17: ``` Promise Rejection: Error: connect ECONNREFUSED ::1:39193 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) { errno: -111, code: 'ECONNREFUSED', syscall: 'connect', address: '::1', port: 39193 } ``` Here's the patch that fixes this for us: // node_modules/mocha-chrome/lib/client.js - const client = await CDP({ port: instance.port }); + const client = await CDP({ port: instance.port, host: '127.0.0.1' }); An alternative patch that would also succeed: // node_modules/chrome-remote-interface/lib/defaults.js - module.exports.HOST = 'localhost'; + module.exports.HOST = '127.0.0.1'; Another option: // node_modules/chrome-remote-interface/lib/external-request.js - const {address} = await util.promisify(dns.lookup)(options.host); + const {address} = await util.promisify(dns.lookup)( + options.host, + {family:'IPv4'}, + ); Thank you @nsainaney for writing this comment in nodejs/node#40702 [^1]: > It appears to be a breaking change with how DNS.lookup works. With > node 16, the lookup would return a IPv4 address but with node 17, it > returns an IPv6 address which will break most REST clients that > hardcode URLS like http://localhost:4040/api if the upstream server > only binds to the IPv4 address (e.g. server.listen('127.0.0.1'…) etc… [^1]: nodejs/node#40702 (comment) Before committing to the 'patch' strategy, I checked to see if either mocha-chrome or chrome-remote-interface had been updated later with this workaround. - chrome-remote-interface accepts a parameter for host, so nope. Makes sense, since you can specify the host manually. - mocha-chrome doesn't parameterize host, and the author of mocha-chrome considers it an obsolete package and is no longer updating it.
- Loading branch information