Hacker News new | ask | show | jobs
by rich_harris 1133 days ago
This is a non-issue in practice — complex types can be expressed in .d.ts files and imported. SvelteKit (not Svelte) has been doing this for a long time and it's fine.
2 comments

I wish this were true. I'm currently dealing with three third-party libraries whose types are out of date with the actual code because they do this.
If those libraries were set up correctly, this would cause typechecking to fail.
It’s usually a non issue for most normal use cases. Some exceptions are truly maddening though, if you have good reason to use them. One off the top of my head that personally peeved me enough to ragequit one of my side projects: you cannot, as far as I’m aware, define an interface and assign its type to a class (neither its static constructor nor its instance members), without redeclaring every single member type in JSDoc. You can’t (again as far as I’m aware) even define types adjacent to their project-local implementation module and treat them the same way as @types/typeRoots. Both of these would be solvable if you could <reference …/> without polluting global scope, but again that’s a behavior only (again as far as I’m aware) available to dependencies.

I’d be thrilled to make the concession to a TypeScript flavor of header/implementation file pairs and skip a build step for huge portions of my work. But I spent way too long trying to figure out how to do it and my only remaining hope that it’s even possible is to wait for the “you don’t know?!” replies. (If it’s not clear here, they’d be very very welcome!)