4 ms·

> - Always enable --noImplicitAny and --strictNullChecks. Without these flags, the type system is barely better than using JS. This is exactly what I did and i

by mercer 10y ago

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

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 mercer 10y ago

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'