3 ms·

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 som

by ash 10y ago

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-TypeScript#non-null-assertion-operator https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

mercer 10y ago
Good point! I was talking about noImplicitAny; strictNullChecks is worth the 'hassle' from the start.
- ash 10y ago
  Why couldn't you use explicit `any` type when you 'need to get shit done'?
  - mercer 10y ago
    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.
- WorldMaker 10y ago
  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'

by ash 10y ago

mercer 10y ago

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

ash 10y ago
Why couldn't you use explicit `any` type when you 'need to get shit done'?
- mercer 10y ago
  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.
WorldMaker 10y ago
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'