Hacker News Reader

Comment by ghh | Hacker News Reader

This is kind of a random Typescript tip, but when migrating regular Javascript, there is an alternative to adding the type 'any' to every object to 'silence' the compiler.

That is to introduce a preliminary type definition. Instead of:

  const oldVar: any = { field: 1, ... }
  function foo(bar: any) { ... }

You can write:

  declare type OldVarType = any

  const oldVar: OldVarType = { field: 1, ... }
  function foo(bar: OldVarType) { ... }

This way, you can signal that it's not just any kind of any, but a particular kind of any, which is now trackable in your codebase.

When you're ready, you can gradually update the OldVarType declaration and solve the compiler type check warnings from there. Union types [1] can be quite useful then too.

[1] https://www.typescriptlang.org/docs/handbook/advanced-types....

View on HN

Ah, that's a neat idea. I wonder if there's any easy way to then scan your code for type aliases that are `any` to make sure you've caught all of those.

Probably best to put all the any type aliases in one place then you know what they are all.

Most development setups have a way to do a regex search through a codebase; You'd be looking for declare type.*any

If you're IDE doesn't do it, then I highly recommend using ack[1]. It's my go-to tool for tasks like this, and I've found it a joy to use.

1: http://beyondgrep.com

Common prefix or suffix? I know in the RxJS community it's not uncommon to suffix an Observable variable like `fooBar$`

I think that would be more trouble than it's worth. Since "any" is a keyword, you wouldn't even need regex to search for it. Something like this would work:

" = any"

This would only show types that are aliases of the "any" type. As a side note, the following would create a compiler error ("cannot find name 'any'") because types are metadata and can't be used as program data.

const something = any;

Heh, sure does bring memories of the C64 BASIC where string-typed variables and functions were marked with a $ suffix :)

Yes! We have several 100% TypeScript applications and we've found TSLint to be invaluable for maintaining code quality - http://palantir.github.io/tslint/

You can ban the `any` type along with lots of other rules. You can also write your own custom rules, or implimnet rulesets by 3rd parties like Microsoft: https://github.com/Microsoft/tslint-microsoft-contrib and ESLint: https://github.com/buzinas/tslint-eslint-rules

Shouldn't my compiler do such things for me?

What do you want the compiler to do in this scenario?

Infer and track types. Just as was described in the parent post.

Both those versions should work the same from the compiler's point of view. But from a programmer's point of view, specifically someone migrating a JS system to TS, it's useful to read "oldVarType" instead of "any", because it tells you that it was just a quick way to migrate rather than necessarily designed to be "any".

Yes, and it would be nice if the compiler could produce such an annotated version automatically, instead of the programmer having to use the highly error-prone technique of typing it all out manually.

For a single function it's not a bug deal, but if you are migrating 10k lines, I'd view it as a near necessity.

So you want the compiler to automatically generate alias types for every un-typed variable and parameter? I assume you would also want the compiler to (somehow?) infer types that should be the same type and merge them, since otherwise the first step is kind of silly. I'd argue that that's a pretty difficult task, tantamount to inferring programmer intent.

Yes, I want merging, but I imagine there could also be an indication that the merge was automatic and in an IDE setting, I'd expect to be able to easily split out the types, if I want.

Reply on news.ycombinator.com