types: fix Session interface reference

[FabianFrank]

now Session actually resolves to the session interface defined in the same files instead of being an unresolved any. goal of this change is to fix #181

before:

after:

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

This doesn't require a new test/benchmark or doc change to the best of my knowledge.

[Uzlopak]

Actually we could need a typing test

See types.test-d.ts

[FabianFrank]

@Uzlopak there's already a typing test for this at

session/types/types.test-d.ts

Line 92 in 6462ff4

expectType<{ id: number } | undefined>(session.user);

and the test doesn't break with this change. it's unfortunate that the types work under test but not when installed as a dependency in another project. frankly, I'm not familiar enough with tsd to figure out how to make the test fail with Fastify.Session.

[Uzlopak]

I will have a look later

[mcollina]

Thanks for opening a PR! Can you please add a unit test? We use tsd for typescript.

[FabianFrank]

@mcollina please see #182 (comment)

[mcollina]

I'm uncomfortable in landing this without a test.

[FabianFrank]

@mcollina there is already a test for this type. how do you think the existing test for this type should change?

[mcollina]

I don't know. I'm not the one proposing the change in this PR.

[climba03003]

LGTM.

Let me explain a bit of the problem.
The local assertion will always pass since as a package point, we know Fastify types before using it.
However, when it comes to the consumer. It will create an infinite loop of referencing. So, it will return any as a result.

For a test, we need to create a dummy package.json, install itself as dependent. Then, assertion the types inside the dummy package. Would it be too heavy as a test?

[FabianFrank]

In #181 (comment) we were able to track this down to the esModuleInterop setting in typescript, so to build on @climba03003's idea of a separate test package, we'd also have to make that test package an ESM module and disable module interop. Then the question is are we comfortable to only test the ESM case or do we want to test the CJS case as well, i.e. have 2 test packages?

[mcollina]

lgtm