0:00 I spoke to [indecipherable , who used to be a member of the TypeScript team, and he mentioned there are four different spaces where types that you don't define come into your application code.

0:11 I'd say there are roughly four spaces where types can come into your projects. The types that get shipped with TypeScript, we would refer to as lib.d.ts. There's the DOM types, which dom.d.ts. There's definitely typed, and then there's included inside your either codebase or your Node Package Manager.

0:32 Lib.d.ts exists to describe JavaScript. JavaScript language spec 2015 had classes and somebody has to ship those to describe that type system further down the line.

0:46 What you're saying is, let's say, const Whatever = Map. Going from this, how would I say, "OK, I want to see where this d.ts file is coming from?"

0:56 Are you on a Mac? You could command and click on that. It should, actually show you.

1:00 We're now on lib.es2015collection.d.ts. This is one of the many, many files in here that represents all of the stuff that JavaScript can do.

1:11 Exactly. Every single one of those is either a spec or a feature collection that's very explicitly about describing the JavaScript spec and nothing else. This one, you've got WeakMap on screen as well as set under there.

1:26 Those are things that were added to JavaScript in the 2015 version of JavaScript. Each one of those files represents a subset of that year's language. If you've got ES2017 installed, then it also includes all of ES2015, etc., etc. The target definition in your tsconfig defines what is the year that you start and then it goes all the way back in those.

1:50 The next space where types come into your project is in the DOM typings.

1:54 Now, a realistic take on what people do with JavaScript is to say, "Hey, most people are working with Web in JavaScript." TypeScript is 10, 12 years old at this point and at that point it was the only use case for JavaScript, especially.

2:11 It was a very reasonable idea and it still probably is to include dom.d.ts as the default. Lib.dom.d.ts is pretty complicated project that outputs a single DOM file and that small iteration file that you saw next to it.

2:26 This one is a separate repo from the TypeScript repo. It is maintained by an outside collaborator who works at Mozilla and is constantly up-to-date with spec changes in web browsers.

2:42 The problem with this one is realistically, you don't want a version your web browsers in the way that you might for your language. Our rules for this are if a feature is in the Web platform in general and you can see it in at least two browsers, that's Firefox, Safari, or Chrome EUMS. It has to be in two of those to be allowed in.

3:08 What we really do is we look at the database behind, I think it's called, "Can I Use This?" Which is a website that lets you say, "Hey, can I use the CSS feature? Can I use this JavaScript feature?" We pull data from that in documentation and turn that into a giant DTS file.

3:26 That is constantly updated. We get notifications about new updates all the time and this always represents the latest version of the DOM.

3:35 The third space is...

3:37 Definitely, typed. That is describing code, which is in JavaScript, but no one has really turned that into TypeScript code. The way to think about that is those last two are, is it a codebase that is made in TypeScript that generates DTS files or is it a JavaScript project that is not got types?

3:58 We don't want to annoy the authors of that JavaScript project by giving them the types to try and maintain, because some of these types are complicated. These types are complicated, the React types are complicated. The React team don't use TypeScript.

4:10 There are a set of absolute heroes that try to map this very complicated system of React into a runtime that can exist inside the type system.

4:23 The fourth space where types can come into your project.

4:25 People ship their own types. Any library that's made in TypeScript will ship its own .d.ts files attached with them. Yeah, exactly, that's a perfect case. RITS UI ships with the JavaScript and the .d.ts.

4:40 That is largely the traditional way in which TypeScript says, "This is how you should define your types." We're not shipping TypeScript to clients. We're shipping JavaScript to clients. Separate from that, there is a definition file.

4:53 This is an established pattern. If you viewed C uses this pattern, where you have a header file, and you have an implementation file. It's very traditional. If you don't ship the .d.ts files, then TypeScript will just say, "I don't know what to do with this," in a TypeScript project. If you're in a JavaScript project, it says, "Hey, I'll give it a shot and see where it goes."

5:11 Here you go. The four different spaces where types can come into your app, lib.d.ts, the DOM typings, definitely typed, and types that ship with libraries that have been built with TypeScript.