Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should fix #2, which is also similar to other issues reported to fastify itself (i.e. see fastify/fastify#2438)
The underlying cause here is jest fiddling with sandboxing, context and globals. The result is that the
Error
global object available to fastify-warning is not the same object in the main node process and thusFastifyWarning instanceOf Error
that is run in the implementation ofprocess.emitWarning
(see https://github.com/nodejs/node/blob/v10.22.0/lib/internal/process/warning.js#L146) fails.The issues caused by jest sandboxing model have been known for a while now (see jestjs/jest#2549 and jestjs/jest#8246) and looks like they won't be solved soon.
This PR works around it by not emitting an error, but rather calling
emitWarning
with string params instead (documented here: https://nodejs.org/dist/latest-v12.x/docs/api/process.html#process_process_emitwarning_warning_type_code_ctor)The downside of this approach is that
warning.create
won't be returning a constructor for an object that inherits fromError
, but that apparently was never used in fastify.Checklist
npm run test
andnpm run benchmark
documentation is changed or added