Q:

When to use types (vs interface) in TS

I cannot determine understand when, if ever, you'd want to use a type instead of an interface for a variable in typescript. Assume the following two:
type User = {
    id: string;
    name: string;
    type: string;
}

interface User {
    id: string;
    name: string;
    type: string;
}

I can define a variable with both exactly the same was const user: User = .... However, here are all the things I can do with interface that I cannot do with types:
// Extension:
interface AdminUser extends User {
    permissions: string[];
    role: string;
}

// Using in abstract method:
abstract class Home {
    abstract login(user: User): void;
}

class AdminHome extends Home {
    login(user: AdminUser) {
        ...
    }
}

Just to name a few.
So my question is: when would you ever want to use a type?

A:

Unless I'm mistaken, you're not entirely clear what the purpose of an interface vs. a type is. 
In OOP terms, interfaces do not have implementations. Types do. So an interface is basically useless unless a type implements it. Also, a type can only extend one other type. But it can implement many interfaces. 
But what's that mean...
Say you have a Car, and a User. Very different types that you don't immediately think of as being the same in any practical way. Some may say, "well, you should create ICar, and IUser". But really, that's just not a practical way to think about interfaces. It would be confusing for User to implement ICar, and/or, ICar just seems to do the same thing as Car. What would be the difference to another programmer looking at the code?
Say you want them both to be (again just for the heck of it), "Self Describable", and you want them both to provide the info the same way. So you'd create:
ISelfDescribable {
   getSelfDescription ( );
}

Now, you'd do this:
Car implements ISelfDescribable {
   getSelfDescription ( return "I am a car!" );
}

User implements ISelfDescribable {
  getSelfDescription ( return ...some other completely different way of getting the info... );
}

An array of these objects would be (think about how else you would do this without interfaces):
Array<ISelfDescribable>

Now you (and any other dev looking at the code) knows for a fact, any object in this array, regardless of the concrete type, implements the "behavior" of ISelfDesribable. If you think about it, there is really no need to EVER know what a type is unless you're implementing it, you just care about the behavior. But you still need the type to implement that behavior. 
Say one day you wanted both these objects to be "Insurable". They should both have a method, "setInsurancePolicy". You could create IInsurable { setInsurancePolicy ( policy : Policy ) }, and implement it in the types. Now you have objects that are both ISelfDescribable and IInsurable, and you can type an array of those objects as either one. 
So for me, the big lightbulb went off when I got my head around that: types (and type hierarchies) should be concerned with concrete things. Interfaces should be concerned with behaviors that can be shared among different types. There's more to it, but that at least gives a notion of why you'd choose an interface, or a type. They represent different things in terms of programming, even if they otherwise appear the same. 
(Addendum: Languages like Scala don't think in terms of interfaces this way. They do have a notion of "behaviors", but you can also implement behaviors, and override them. That may be too much academic blather for this particular question, but hey I need to kill all the monsters in the dungeon, not just the ones for the quest). 

