fix: call fs.createReadStream lazily#2357
Conversation
|
Hello dear nock maintainers! I'd like to know if there's any particular reason this PR (or either of the other two PRs I opened at the same time, #2355 and #2356) have not been looked at yet. For starters, my branch is now out of date, and the CONTRIBUTING.md file says I should be targeting a beta branch (but there's none). But aside from that, is there anything wrong or missing? Updating merging the latest changes to the branch is something that can be done orthogonally from the review. |
fs.createReadStream lazily
aed6c64 to
a6490c3
Compare
a6490c3 to
e344eb5
Compare
|
@mikicho Branch updated - rebased on top of main, and I also split my one commit into 3 (separated individual test additions from the fix itself) |
a09e296 to
73757d4
Compare
|
🎉 This PR is included in version 13.5.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 14.0.0-beta.19 🎉 The release is available on: Your semantic-release bot 📦🚀 |
When using
replyWithFile, a ReadStream is immediately created wih the file path. When the mock is hit, another ReadStream is created immediately if the interceptor is configured to be set again or if its scope has_persistset. When callingnock.removeInterceptor, the ReadStream isn't closed.As a result, it's not possible to delete the folder where the file exists on Windows unless implementing a workaround like multiple
fs.rmcalls.This PR removes the eager
fs.createReadStreamcall when setting up the interceptor and instead configures the route to createthe stream lazily, in a callback invoked when intercepting a call. There is no longer any need for
replyWithFile-related logic inInterceptor#markConsumed().I also added an extra test for
replyWithFile+persist(), which I think makes coverage a bit more complete.Fixes #2354