Releases: mswjs/interceptors
Releases · mswjs/interceptors
v0.4.0
Breaking changes
- Creating a new
RequestInterceptor
instance now requires to pass a list of interceptors to use. It's recommended to use the/presets/default
interceptors preset for backwards-compatibility.
import { RequestInterceptor } from 'node-request-interceptor'
+import withDefaultInterceptors from 'node-request-interceptor/presets/default'
-new RequestInterceptor()
+new RequestInterceptor(withDefaultInterceptors)
Features
-
Supports granular interceptors configuration (#48), allowing to specify which request issuing modules to intercept on the usage level. The list of published interceptors:
node-request-interceptor/interceptors/ClientRequest
node-request-interceptor/interceptors/XMLHttpRequest
To use one or multiple interceptors import them and provide as an argument to RequestInterceptor
class:
import { RequestInterceptor } from 'node-request-interceptor'
import { interceptXMLHttpRequest } from 'node-request-interceptor/interceptors/XMLHttpRequest'
const interceptor = new RequestInterceptor([interceptXMLHttpRequest])
interceptor.use(/* refer to README for usage examples */)
Bug fixes
v0.3.6
Changes
ClientRequest
options.uri.protocol
is taken into account when deciding on the request's protocol.
XMLHttpRequest
this.user
andthis.password
initializers are now removed, the values default toundefined
.this.async
has a default value ofundefined
,true
when forwarded (previouslyfalse
).
Bug fixes
v0.3.5
v0.3.4
v0.3.3
Bug fixes
- Fixes an issue that resulted into a mocked
statusText
not being set on theClientRequest
instance (mswjs/msw#279, #35).
v0.3.2
Bug fixes
- Fixes an issue where a request body and encoding where not accepted in the
ClientRequest.prototype.end
method (#32, #33). - Fixes an issue where request headers that were added after the
ClientRequest
has been constructed were not present on the mocked request object, and were not propagated to the original request object (#32, #33).