What is the expected behavior?
Using the new signature for http.request(url, options[, callback])/http.get(url, options[, callback]) (introduced in Node.js v10.9, should work with nock.
What is the actual behavior?
With nock (by merely requireing nock), it throws:
events.js:288
throw new errors.ERR_INVALID_ARG_TYPE('listener', 'Function', listener);
^
TypeError [ERR_INVALID_ARG_TYPE]: The "listener" argument must be of type Function. Received type object
at ClientRequest.once (events.js:288:11)
at new ClientRequest (_http_client.js:150:10)
at Object.request (http.js:41:10)
at ...\node_modules\nock\lib\intercept.js:405:16
at Object.module.request (...\node_modules\nock\lib\common.js:140:14)
at requestWithUrlAndOptions (...\script.js:27:5)
at Object.<anonymous> (...\script.js:42:1)
at Module._compile (internal/modules/cjs/loader.js:689:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Module.load (internal/modules/cjs/loader.js:599:32)
Possible solution
I haven't looked at the code, but I suspect nock assumes the second argument is always the callback and uses it as such, whereas in Node.js 10.9+, the second argument can be an object (with the third being the callback). It should be trivial to detect that situation and pass the correct arguments to http.request() (or something like that 😁).
How to reproduce the issue
Runkit: Example link
Does the bug have a test case?
(Not sure wht this means.)
Versions
| Software |
Version(s) |
| Nock |
All (at least up to 10.0.0) |
| Node |
10.9+ |
What is the expected behavior?
Using the new signature for
http.request(url, options[, callback])/http.get(url, options[, callback])(introduced in Node.js v10.9, should work withnock.What is the actual behavior?
With
nock(by merelyrequireingnock), it throws:Possible solution
I haven't looked at the code, but I suspect
nockassumes the second argument is always the callback and uses it as such, whereas in Node.js 10.9+, the second argument can be an object (with the third being the callback). It should be trivial to detect that situation and pass the correct arguments tohttp.request()(or something like that 😁).How to reproduce the issue
Runkit: Example link
Does the bug have a test case?
(Not sure wht this means.)
Versions