Overriding the type of `Response.json`

[silver moss]

Hey! I’m using the following pattern to add some type safety to my API responses:

type ApiReturn =
  | {}
  | {}
  | {};

// ...

return Response.json({
  // ...
} satisfies ApiReturn);

Is it possible to override the type of Response.json so it only accepts values matching the ApiReturn type? I played around with this idea a bit but couldn't get it to work.

This might not be specific to Bun's types, but I saw that they do some trickery with Bun.__internal.UseLibDomIfAvailable so I presume it would require a unique solution.

[solar slate]

@desert magnet

[desert magnet]

Unfortunately it's not possible @silver moss

For some more context, please see this (closed) pull request I submitted a few months ago to TypeScript's DOM lib generator - https://github.com/microsoft/TypeScript-DOM-lib-generator/pull/1941

The issue is that TypeScript doesn't let us extend the declaration of a variable, there's no concept of "interface merging" (or something that looks like interface merging) there

the solution would be for the typescript dom generator to create var Response: ResponseConstructor (Which is what my pull request did) but the maintainers did not like it, unfortunately.

[silver moss]

makes sense

[silver moss]

if i understand correctly, they want to go forward with #222 instead? been open since 2017 👀

[desert magnet]

yeah😢

[silver moss]

This is unfortunately way above my TS knowledge, thanks for the response though

[desert magnet]

my recommendation for you is a helper around Response.json

like response({...})

[solar slate]

response<smth>() would be fun lol, but idk if it would work the same as satisfies

[silver moss]

That was my initial idea too, but the request-response API is great as is, I don't want to wrap another thing around it - even if it's as simple as that.

I'm gona keep using satisfies, it does what I want it to. I just loved the idea of enforcing that Response.json can only take certain types.

[desert magnet]

cool!

[desert magnet]

@silver moss Feel free to leave a comment explaining on the closed PR if you feel comfortable doing so, explaining that you need this feature/want to extend the Response constructor, but are unable to because of this limitation currently

The alternative/proposed solution from a few years ago isn't really moving much 😢

[silver moss]

Done

I was already thinking of doing that, but I then discarded the idea because I thought that if the needs of a Bun maintainer were dismissed, my needs wouldn't even be considered.

[desert magnet]

I think any usage/proof of it being problematic is useful. So thank you very much!

[silver moss]

Any time. I hope your proposal or a different implementation that solves this limitation gets merged.

I can even ask some friends to also comment on the issue 😛 - idk if that's frowned upon in the OSS world

On a related note, I've been stuck on a TS issue. I came up with a couple of workarounds, but I could really use someone with deep TS knowledge to help me pick the right one. It's not specific to @types/bun, but I would appreciate it if you could comment on it.

I put a minimal example and the list of my ideas here.

I understand if you don't have the time / don't want to, but I thought I'd shoot my shot and ask

[desert magnet]

No that’s okay, but thank you! The TypeScript team are great and we chat to them occasionally. The team maintaining the dom generator are also majority volunteers anyway. We want to foster a good relationship with them, they do excellent work. I only asked you since you ran into the problem yourself!

[desert magnet]

Can you dm it to me and ill take a little bit of a look today?

[desert magnet]

@silver moss

I didn't really check the solution much but just adding a root tsconfig fixed it - note that there was one issue in either @types/node or @types/bun which you'd be able to ignore by re-enabling skipLibCheck

the tsconfig I copy pasted it from alistair.blog/strict-tsconfig

I think this is something to do with how tsconfig thinks about monorepos. I'm not quite sure. the differences are very subtle

anyway here's the commit https://github.com/alii/petdomaa100-ts-issue-demo/commit/594b114f9e01eeb7eeb04e987bd3ce175f0605a8

[silver moss]

Thank you so much! I had to upgrade bun from 1.3.1 to 1.3.3 for it to work, but it now works.
Though the root tsconfig wasn't needed for typecheck to pass after all. Is that recommended to have?

[silver moss]

I discovered already. I might even use your Rekordbox history parser one day.

[silver moss]

Actually, setting "configVersion": 0 alone in the lockfile solves the issue. If I remember, this has to do with hoisted installs, which would explain the fix.

Last question, I promise, aren't hoisted installs an unsafe idea?

[desert magnet]

Oh, that's interesting

[desert magnet]

Hoisted installs are like, mostly fine.

They are the default for most package managers still in most cases

[silver moss]

I will move forward with this because it's literally a 1-line fix and I can just move on, but I will eventually read through the TS docs and try to make it work with isolated installs.

Thanks for your help!

[desert magnet]

The solution might be something to do with project references @silver moss

https://www.typescriptlang.org/docs/handbook/project-references.html

but im not sure

I actually dont know what the real problem is yet, i just know that I did something, ran tsc and it worked

😅

[silver moss]

Will give it a read when it's time for the inevitable refactor. 🤓

[desert magnet]

Lol