Closed greenkeeper[bot] closed 5 years ago
devDependency
nock was updated from 10.0.6
to 11.3.2
.Update to this version instead π
Nock 11 includes many under-the-hood improvements, including a fully offline
test suite and 100% test coverage. The codebase was also converted to ES6
syntax and formatted with Prettier. Leaning on the test coverage, some
substantial refactors have begun.
Many bug fixes are included. See the detailed changelog below or the
compare view for details.
http.request
signatures added in Node 10.9.conditionally(() => true)
afterRecord()
afterRecord()
returns a string, the.reply()
can now be async/promise-returning..reply()
or .defaultReplyHeaders()
,For many developers no code changes will be needed. However, there are several
minor changes to the API, and it's possible that you will need to update your
code for Nock to keep working properly. It's unlikely that your tests will
falsely pass; what's more probable is that your tests will fail until the
necessary changes are made.
Nock 11 requires Node 8 or later. Nock supports and tests all the "current"
and "maintenance" versions of Node. As of now, that's Node 8, 10, and 12.
In Nock 10, when reply()
was invoked with a function, the return values were
handled ambiguously depending on their types.
Consider the following example:
const scope = nock('http://example.com')
.get('/')
.reply(200, () => [500, 'hello world'])
In Nock 10, the 200 was ignored, the 500 was interpreted as the status
code, and the body would contain 'hello world'
. This caused problems
when the goal was to return a numeric array, so in Nock 11, the 200 is
properly interpreted as the status code, and [500, 'hello world']
as the
body.
These are the correct calls for Nock 11:
const scope = nock('http://example.com')
.get('/')
.reply(500, 'hello world')
const scope = nock('http://example.com')
.get('/')
.reply(500, () => 'hello world')
The .reply()
method can be called with explicit arguments:
.reply() // `statusCode` defaults to `200`.
.reply(statusCode) // `responseBody` defaults to `''`.
.reply(statusCode, responseBody) // `headers` defaults to `{}`.
.reply(statusCode, responseBody, headers)
It can be called with a status code and a function that returns an array:
.reply(statusCode, (path, requestBody) => responseBody)
.reply(statusCode, (path, requestBody) => responseBody, headers)
Alternatively the status code can be included in the array:
.reply((path, requestBody) => [statusCode])
.reply((path, requestBody) => [statusCode, responseBody])
.reply((path, requestBody) => [statusCode, responseBody, headers])
.reply((path, requestBody) => [statusCode, responseBody], headers)
.reply()
can also be called with an async
or promise-returning function. The
signatures are identical, e.g.
.reply(async (path, requestBody) => [statusCode, responseBody])
.reply(statusCode, async (path, requestBody) => responseBody)
Finally, an error-first callback can be used, e.g.:
.reply((path, requestBody, cb) => cb(undefined, [statusCode, responseBody]))
.reply(statusCode, (path, requestBody, cb) => cb(undefined, responseBody))
In Nock 10, errors in user-provided reply functions were caught by Nock, and
generated HTTP rersponses with status codes of 500. In Nock 11 these errors
are not caught, and instead are re-emitted through the request, like any
other error that occurs during request processing.
Consider the following example:
const scope = nock('http://example.com')
.post('/echo')
.reply(201, (uri, requestBody, cb) => {
fs.readFile('cat-poems.txt', cb) // Error-first callback
})
When fs.readFile()
errors in Nock 10, a 500 error was emitted. To get the
same effect in Nock 11, the example would need to be rewritten to:
const scope = nock('http://example.com')
.post('/echo')
.reply((uri, requestBody, cb) => {
fs.readFile('cat-poems.txt', (err, contents) => {
if (err) {
cb([500, err.stack])
} else {
cb([201, contents])
}
})
})
When .reply()
is invoked with something other than a whole number status
code or a function, Nock 11 raises a new error Invalid ... value for status code.
Callback functions provided to the .query
method now receive the result of
querystring.parse
instead of qs.parse
.
In particular, querystring.parse
does not interpret keys with JSON
path notation:
querystring.parse('foo[bar]=baz') // { "foo[bar]": 'baz' }
qs.parse('foo[bar]=baz') // { foo: { bar: 'baz' } }
In Nock 10, duplicate field names provided to the .query()
method were
silently ignored. We decided this was probably hiding unintentionally bugs
and causing frustration with users. In Nock 11, attempts to provide query
params more than once will throw a new error
Query parameters have aleady been defined. This could happen by calling
.query()
twice, or by calling .query()
after specifying a literal query
string via the path.
nock('http://example.com')
.get('/path')
.query({ foo: 'bar' })
.query({ baz: 'qux' }) // <-- will throw
.reply()
nock('http://example.com')
.get('/path?foo=bar')
.query({ baz: 'qux' }) // <-- will throw
.reply()
Paths in Nock have always required a leading slash. e.g.
const scope = nock('http://example.com')
.get('/path')
.reply()
In Nock 10, if the leading slash was missing the mock would never match. In
Nock 11, this raises an error.
The reqheaders
parameter should be provided as a plain object, e.g.
nock('http://example.com', { reqheaders: { X-Foo: 'bar' }})
. When the
headers are specified incorrectly as e.g. { reqheaders: 1 }
, Nock 10 would
behave in unpredictable ways. In Nock 11, a new error
Headers must be provided as an object is thrown.
nock('http://example.com', { reqheaders: 1 })
.get('/')
.reply()
In Nock 10, the ClientRequest
instance wrapped the native on
method
and aliased once
to it. In Nock 11, this been removed and request.once
will correctly call registered listeners...once.
In Nock 10, when the method was not specified in a call to nock.define()
,
the method would default GET
. In Nock 11, this raises an error.
In very old versions of nock, recordings may include a response status
code encoded as a string in the reply
field. In Nock 10 these strings could
be non-numeric. In Nock 11 this raises an error.
request.end()
, including request.end(cb)
in Node 12..destroy()
method.complete
property is set whenunref()
functionIf you discover bugs in this release, please open a bug report on the Nock repo.
Interceptor.query
twice throws an error.query
conditionally()
(#1488) (24e5b47)IncomingMessage.client
for parity with real requests (dc71a3b), closes /github.com/nodejs/node/blob/2e613a9c301165d121b19b86e382860323abc22f/lib/_http_incoming.js#L67unref
to Socket (#1612) (a75f49f)req.end(cb)
compatibility with Node 12 (#1551) (31623fb).matchHeader()
with allowUnmocked
(#1480) (d6667f0)req.end(cb)
; prevent TypeError in Node 12 (#1547) (9a494da), closes #1509new ClientMessage()
is invoked with no options (#1386) (6d2a312)The new version differs by 10 commits.
65a8a6a
fix(types): use export = and declares (#1695)
d86245f
refactor: Refactor net connect tests (#1688)
ad000ef
docs: Add "Common issues" section documenting got automatic retrying (#1687)
8e78ffe
style: Minor style improvements (#1693)
949d264
test: Add todo test for conflict between hostnames (#1109)
057bbdf
fix: add extension to main field in package.json (#1683)
89eb03a
refactor: replace some lodash usage with native (#1685)
6ca2bd3
Update eslint-config-standard to the latest version π (#1681)
e0930f8
feat: afterRecord
support for custom formatting after recording. (#1682)
de9c40b
feat(socket): propagate errors from destroy method (#1675)
See the full diff
devDependency
nock was updated from 10.0.6
to 11.3.3
.devDependency
nock was updated from 10.0.6
to 11.3.4
.devDependency
nock was updated from 10.0.6
to 11.3.5
.
The devDependency nock was updated from
10.0.6
to11.1.0
.This version is not covered by your current version range.
If you donβt accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.
Publisher: nockbot License: MIT
Find out more about this release.
FAQ and help
There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those donβt help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).Your Greenkeeper bot :palm_tree: