TypeScript would complain about that snippet too.

function getOptions() { return { num: 42, str: "val" }; }

var __options__ = getOptions();

type Options = typeof __options__;

var options: Options = {

    ^^^^ Type is not assignable

    num: "hi",
    str: 42

};

I love TS and cannot speak enough good things about it.

But in your TS example, the code would execute. Not in the Flow example, where it's just an annotation.

There are hacks and other approaches, documented here:

https://github.com/Microsoft/TypeScript/issues/6606

>But in your TS example, the code would execute.

Incorrect. It's a type alias so it uses "type typeof" not "value typeof". It doesn't have the problem that the issue you linked to is about.

https://www.typescriptlang.org/play/#src=function%20getOptio...

Observe the JS output contains no `typeof` and that the type `Options` is considered to be the same as `{ num: number, str: string }` if you hover over it.

I don't understand. In your transpiled code, getOptions is clearly being called in JS.

In flow, getOptions() wouldn't be in the transpiled code at all.

Imagine the body of getOptions as an extremely expensive computation. Some prime calculation. But you only want its return type. In flow comments, you can get it.

In the approach of your snippet, you could get it, but it will execute the full function with the full price.

My bad, I thought you were referring to `typeof` being the code that still executes. Now I read that tweet more carefully and noticed the `getOptions()` call is in a comment. A strange feature that I suppose is useful when dealing with complex anonymous types, though in my experience such complex types tend to be named.

The minifier would get rid of the __options__, and also the function getOptions because both are not used in the resulting code. You need a minifier in any serious project.

It wouldn't. getOptions() could have side effects that we want to run. Imagine inside of getOptions we have a prompt() call to fill in some of the options...

Does Typescript still require you to have definitions for every library in order to use the library? One thing I love about Flow is that it doesn't have that requirement. You can start using a new library, and later on if you find that type safety in that library's exports would be useful, then you can look for or write definitions then. You're not blocked from adopting the library. I find for many of my dependencies that I use in a few spots it's not really important for me to have definitions for.

I don't think that Typescript ever did require that? AFAIK, it has always been possible to just declare the variable as "any" type and use it as if it were untyped.

I thought I remembered using require statements and getting errors from the typescript compiler that it couldn't find the (typescript definitions for the) file.

Can confirm. This has been my experience.

technically you do need to define at the top level, but no, not in a practical sense:

declare var $: any;

$( "element" ).compiler.leaves.you.alone

You can always add a quick and dirty definition like:

declare module 'themodule' { var mock: any; export default mock; }

But unless the lib doesn't propagate through your code at all, it pays of to give it proper typings.

In the rare cases we find a library that doesn't have a typescript definition, we just do:

   declare var Thing : any;

In a global definition file.

Pro tip. We've got a lot of mixed js and ts at the moment and when you're really lazy you can take advantage of how every object is a dictionary in js and just do something like `window["notification"]` instead of window.notification, which resolves to an 'any' type in ts.

Obviously you should try and minimise that usage, but it's a useful trick to know.

Is that still the case with the recent update to TypeScript now that it also typechecks object['prop']?