search

fastify / fastify-websocket

basic websocket support for fastify
MIT License
400 stars 74 forks source link

Added SchemaCompiler, TypeProvider, and Logger to types. #225

Closed teastman closed 2 years ago

teastman commented 2 years ago

https://github.com/fastify/fastify-websocket/issues/213

Fixed TypeProvider typings in its WebsocketHandler by adding SchemaCompiler, TypeProvider, and Logger. Attempted to mirror the style used in fastify route.d.ts.

kibertoad commented 2 years ago

Thanks! Can you add tsd tests for this fix?

teastman commented 2 years ago

For sure! Added.

kibertoad commented 2 years ago

tests are failing

teastman commented 2 years ago

Well that's super embarrassing, I've fixed them.

Semi-related question. Does the last test in hooks.js fail on your local machine on a fresh master branch pull? I can clearly see it's not failing in the CI, but on a completely fresh clone it's only calling 5 t assertions but starts with t.plan(6). It looks like the t.fail() inside the fastify.get(...) never gets called.

` FAIL ​ test/hooks.js ✖ test unfinished

test/hooks.js
362 | })
363 |

364 | test('Should not hijack reply for an WS request to a WS route that gets sent a normal HTTP response in a hook', t => {
| ^
365 | t.plan(6)
366 | const stream = split(JSON.parse)
367 | const fastify = Fastify({ logger: { stream } })

test: Should not hijack reply for an WS request to a WS route that gets sent a normal HTTP response in a hook stack: | Object. (test/hooks.js:364:1) Module.replacementCompile (node_modules/append-transform/index.js:60:13) Object. (node_modules/append-transform/index.js:64:4) `

Uzlopak commented 2 years ago

t.fail is the bailout. If you hit t.fail then your test failed. So it is correct that the count is lower, because you dont want to hit the t.fail anyway.