Hacker News Reader

Comment by stevebmark | Hacker News Reader

"type hell" seems to be far worse than "dependency hell," where the open source type definitions you use can have minor inconsistencies with each other, many of which are out of your control, causing lots of useless type errors in any project with even medium complexity. This forces engineers to ignore type errors, defeating the purpose of Typescript entirely.

Has anyone had a truly pleasant experience with Typescript in a medium to large project?

View on HN

> "type hell" seems to be far worse than "dependency hell," where the open source type definitions you use can have minor inconsistencies with each other, many of which are out of your control, causing lots of useless type errors in any project with even medium complexity.

Tried twice to wrap my head around what you are even talking about.

TypeScript is totally wonderful. It's also optionally typed.

I use it on a non trivial project with multiple teams.

Was introduced to it last year and it's fantastic compared to plain js.

Example: https://imgur.com/oR3Nk8q

This was generated by one line of code, simply applying the hoist-non-react-statics library as recommended by the official React docs https://reactjs.org/docs/higher-order-components.html#static...

JavaScript in many cases can be too dynamic to be properly typed. I'd rather have it than not - it has saved my ass a good number of times - but let's not pretend TS/Flow is totally wonderful.

I've only recently started into React, but my impression is because many React teams use Flow or nothing at all, the Typescript types definitely lag behind releases.

At some point I hope to sit down and start filing bugs/sending PRs to fix many of the React Typescript types I find, but in the meantime there are several React modules I've replaced the with just `declare module 'react-thing'` to jus any-type it and move on.

Looks like a jetbrains IDE, I'm a massive fan of intellij and it's my goto programming environment but it's type error messages with typescript are terrible compared to vscode (enough that if I can't understand what the hell it's saying I'll boot vscode).

It's about the one thing I can really ding intellij for at the moment.

Error messages like that are pretty bad, yeah. I'm still a fan of TS myself though, the challenge is that there's some less-well-designed JS libraries that are, like you said, too dynamic to be properly typed.

It's bringing OOP back from having almost been forgotten, and with it, a reminder of proper library design and data types.

Yes. We develop a large Angular app. When the framework itself is written in TypeScript, and by extension, most of the ecosystem code ends up being TypeScript as well, and we have not really faced any major typing issues.

On the other hand, when writing server code targeting Node, with lots of dependencies on micro-libs, I've definitely had the experience of struggling with outdated or incorrect type definitions.

However, nowadays TypeScript has much better interoperability with untyped JS code. You can generally import an untyped JS module with the minimum of ceremony and have it Just Work (the type will be "any", so you don't get intellisense).

I find the best approach is to import types for the big libs you are using, like Express, and leave the micro-libs untyped. That way you get the benefit of types on your own code and your interactions with the framework, but can still leverage other code when you need to without giving yourself a headache.

Resolving conflicts between third party typings from DefinitelyTyped has cost me a lot of time over the last couple of years. The typings we use are maturing a bit, but at one point someone merged a completely unnecessary refactoring of the React types that caused compatibility problems for months until all other dependencies were upgraded.

Using yarn.lock means it never breaks unless we specifically choose to upgrade though, so it's still worth the increased productivity and safeness from TypeScript, which is awesome as a language especially combined with VS Code.

DT has a problem in that they try to track the semver breaks of upstream in their npm packages, but don't have a good way to handle semver breaks caused by type refactors/cleanups/etc.

DT packages almost need _two_ version numbers that npm checks for semver breaks, but how to make that work is an open question and an interesting edge case in package management.

(I got some hate for one of my refactors, that I needed to get my own code to type correctly, that touched quite a few DT packages in the "middle" of an upstream major version, so I know this pain quite directly from both sides.)

Lucidchart and Lucidpress are large projects that are almost entirely TypeScript on the frontend. The team really likes it. We use TypeScript and Angular that is compiled using Tsickle and the Google Closure Compiler.

It's not perfect, but we have found the types to be very nice when working on a large code base with lots of people. Dev development cycle remains quite fast.

There's a way to fix both: Don't multiply dependencies, especially the ones of low quality.

In the worst case scenario, revert to local (checked-in) type definitions and fix it.

It never was a problem for me after more than 5 big TS projects.

My company's app is around 40k lines of TypeScript and our experience has been GREAT. There have been occasional hiccups when upgrading dependencies, but they're few and far between, and the safety and clarity the types give is more than worth it.

Reply on news.ycombinator.com