Hacker News Reader

Comment by ash | Hacker News Reader

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...

View on HN

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

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'

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.

Reply on news.ycombinator.com