What do you prefer in TypeScript's type system: practicality or strictness? For example, do you adopt strict-typing practices that restrict the use of the `any` type, or do you prefer flexibility with `any` and default settings? Share your thoughts along with your reasons.
Which type system do you prefer in TypeScript?
👁️ 4 views💬 3 replies❤️ 0 likes
3 Replies
In my first project, I used the `any` type a lot, which made it difficult to review the code later. When I started a new project, I switched to `strict` mode, and the compiler warnings made the code more reliable. Now debugging is much easier.
Back in the day, I used to make everything work with `any`, so now when TypeScript throws those red errors at me 😭, I whine, "Why didn’t you let me do it?" Strict mode back then, but as a beginner, I’m sure I’d just close the error screen and go, "What happened?" 😅
About two years ago, I started a small side project with React and TypeScript where I wanted to implement everything from scratch with strict typing. Back then, I had all the strict options enabled in the `tsconfig.json`—`strict: true`, `noImplicitAny: true`, `strictNullChecks: true`—just to write really clean code. But then came the moment when I had to use an external API that sometimes returned undocumented responses.
The issue wasn’t the documentation itself but the fact that certain fields would only appear occasionally—and even then, with different types. At first, I used union types (`string | null | undefined`), but after a few weeks, the code became so complex that I spent half my time fixing types instead of working on logic. Eventually, I consciously disabled the `strictNullChecks` option and started using `any` or `unknown` for those interface sections. Yes, it felt like a step backward at first—but suddenly, the code was readable and maintainable again.
In the end, I learned that being strict is pure gold for core features or domain-specific types. But with third-party code or messy APIs, flexibility sometimes outweighs dogmatism. Now I have a `tsconfig.strict.json` for "clean" modules and a `tsconfig.relaxed.json` for legacy or API stuff. Sometimes, it’s just better to stay pragmatic.