Hacker News Reader

Comment by ervine | Hacker News Reader

Why is `any` allowed at all? Enable strict mode, set up your linter, don't allow any implicit or explicit `any` anywhere.

Without this, Typescript is next to useless. Not knowing if the types are good is worse than no types at all.

View on HN

FYI, TypeScript strict mode does not prevent explicit `any` (only implicit `any`).

You'd need to reach for something like https://typescript-eslint.io/rules/no-explicit-any/

For sure, linting is just as necessary as typescript for a sane codebase.

Progressive typing of an untyped code base. Types that are too complex to represent in that type system.

  * Common functions such as parsing functions in languages that don't support function overloading

  * "equals" and other global functions.

Typescript have solutions for both of those problems: conditional types and generics

Yep, adopting strict after the fact is a different conversation, but one that has been talked about a bunch and there is even tooling to support progressive adoption.

Types that are too complex... hmmmm - I'm sure this exists in domains other than the bullshit CRUD apps I write. So yeah, I guess I don't know what I don't know here. I've written some pretty crazy types though, not sure what TypeScript is unable to represent.

Progressive code QA in general is IMO an underexplored space. Thankfully linters have now largely given way to opinionated formatters (xfmt, black, clang-format) but in the olden days I wished there was a way to check in a parallel exemptions file that could be periodically revised downward but would otherwise function as a line in the sand to at least prevent new violations from passing the check.

I'd be interested in similar capabilities for higher-level tools like static analyzers and so on. The point is not to carry violations long term, but to be able to burn down the violations over time in parallel to new development work.

This is how we introduced and work with clang-tidy. We enabled everything we eventually want to have, then individually disabled currently failing checks. Every once in a while, someone fixes an item and removes it from the exclusion list. The list is currently at about half the length we started out with.

> not sure what TypeScript is unable to represent.

I want a type that represents a string of negative prime numbers alternating with palindromes, separated by commas.

Oh yeah, you have to get into branded types for this I think, which means a parsing step. Fair point.

Important note: TS doesn't let you enable strict mode on per-file basis. Flow allowed that.

Sometimes you don't have the type for something, especially if it's 3rd party code. For example, if you are integrating recaptcha with your page: https://developers.google.com/recaptcha/docs/loading

You could try to craft your own type to match google's schema or hunt down 3rd party types, but just doing `(window as any)["__grecaptcha_cfg"]` gets the job done much faster and it's fairly isolated from the rest of the code so it doesn't matter too much.

Yeah, those are few and far between, generally there will be a DefinitelyTyped for anything popular, and you start choosing libs that are written in TypeScript over ones that aren't.

But for your own handwritten application code, there is no excuse to use `any`.

You don't have to provide complete types. If you know what you need to access, and what type to expect (you darn well should!), you only have to tell TypeScript about those specific properties and values.

Generally, the conveniences of allowing any are swamped by the mess it accumulates in a typical team.

Agreed; with 3rd party APIs I type down to the level of the properties I actually need. And when I use a property but don't care what the type is, I use `unknown`. That will throw an error if the type matters, in which case, you can probably figure out what's needed. Although I agree with the article that sometimes fudging the rules is acceptable, it's extremely rare that a 3rd party API is so difficult it's worthwhile. And enforcing `any` as an error means you have to be very intentional in disabling the linter rule for a particular line if that really is the best option.

When you quarantine third party code with an adapter (which you should probably be doing anyway), you can make your adapter well-typed. This is not hard to do, and it pays dividends.

TypeScript has "unknown" for this, forcing you to cast it, possibly to any, every time you use it. A much better type for your variables of unknown type!

Reply on news.ycombinator.com