Hacker News Reader

Comment by mercer | Hacker News Reader

> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS.

This is exactly what I did and it's the main reason I keep dropping TypeScript because I 'need to get shit done'!

It's good advice though, and I would definitely advise new TypeScript users (especially those unfamiliar with type systems) to at least try it. But if it results in giving up and going back to just js, it might be worth going with the 'barely better' approach and only enable those flags if you're more comfortable with TypeScript.

View on HN

strictNullChecks errors are easy to fix:

1. Add `| null` or `?` for things that could be null/undefined.

2. Start handling "is this thing null?" cases. In some occasions it could be annoying. E.g. when you are absolutely sure it's not null. E.g. in tests. TypeScript provides `!` operator for that:

    interface Baz {
      foo?: string;
    }

    let bar = (t: Baz) =>
      // yes, I'm sure
      t.foo!.length;

https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

Good point! I was talking about noImplicitAny; strictNullChecks is worth the 'hassle' from the start.

Why couldn't you use explicit `any` type when you 'need to get shit done'?

Mostly because it caused a huge list of error messages that I found difficult to get rid of. Some of it libraries, IIRC, and some of it my own code. Perhaps for some this would encourage them to one-by-one squash these messages, but in my case it made me go for what was familiar and not written in angry and red letters. I found it easier to introduce TypeScript from an opt-in perspective.

Explicit any is usually also easy enough of a hassle to deal with: when you get a compiler complaint add an `: any` or `as any` somewhere and whatever necessary parentheses to scope that right. Optional: treat `: any` and `as any` as TODO or HACK markers to return to in the fullness of time (refactoring/fixing).

Dealing with other people's modules has also gotten much easier in recent versions of Typescript. To define a module name as any-typed the boilerplate has shrunk to a bare minimum:

    declare module 'name-of-the-module'

Even better, module names in recent Typescript versions accept wildcards:

    declare module 'some-big-node-library/**/*'
    declare module '**/*.css'
    declare module '**/*!text'

Reply on news.ycombinator.com