Transcript from the "Type-Checker" Lesson
>> Mike North: So the next thing am gonna do is obtain a reference to the type checker. The type checker, which is part of the compile, it is what takes all of the types and the interface you create. And the abstract syntax tree which is the in memory representation of your code, right?
[00:00:20] All of the functions and the arguments and everything and it binds them together and identifies what is going to actually typed check. What is going to work? Make sure everything is type equivalent. So it's gonna be the source of a lot of the information that we're gonna use to log out documentation.
[00:00:43] We're just gonna log it to the console to keep things nice and simple. Next, we'll use the type checker to obtain the TypeScript symbol and the symbol is something that can be imported or exported. It's something with a name, remember you have three slots on a symbol, value, type, and namespace, that's what we are working with here.
[00:01:09] And each file is associated with one. So we are going to take all of our files, iterate over them, and for each file, we're going to ask the symbol, sorry, ask the checker for the symbol at the location of that file. This is just the way you get, we're effectively using the language server a little bit here.
[00:01:34] We're saying, we're querying the checker saying, here's a location. It is character zero in the file, basically. Give me whatever the tool tip would be there, like what is the symbol? And then we're filtering out anything that might be undefined. If there was a compile error of some sort, or something was really wrong with one of our declaration files, some files might not be associated with the symbol.
[00:01:59] If they couldn't successfully type check and we had our TypeScript settings really relaxed, some of these might come back like, I can't give you anything for this, it's just gone.
>> Mike North: So now we have symbols,
>> Mike North: And I'm just gonna uncomment this block here and we'll just kinda walk through it's step by step.
>> Mike North: Actually, let's try it out incrementally. So I'm just going to logout each symbols name. We'll start there, that's a good start.
>> Mike North: Okay, so this is giving us basically the same thing as before. Let me just make sure my other console log is gone, and it is.
[00:02:53] So this must be producing this output down here. A symbol associated with a file, it's name, is gonna be part of that file. So if the file has exports, we will enter this branch here. So let's try to compile that and run it.
>> Mike North: And we're just, symbol has a property called exports, and I'm just grabbing that right off of the symbol.
[00:03:26] Looks like it does have exports, so let's iterate over the exports. Their type happens to be something called an UnderscoreEscapeMap, it's a dictionary.
>> Mike North: Sorry for all the scrolling, it's just I wanna reveal this bit by bit so we can all follow along. So we're gonna iterate over the export.
[00:03:52] And for each export, we're gonna log out its name and use this technique with a type checker to obtain its type. This is the exact same thing we used to get each file's symbol, getSymbolAtLocation, getTypeAtLocation. So this will give us a type, and then this is typeToString, self-explanatory.
[00:04:17] Let's see what this looks like.
>> Mike North: Here we go, there's the name of the symbol that's this right here. And then this prints out this string, which looks a lot like what we're seeing in our tool tips. Now, there are couple steps involved here, but really, once we create our program, get ahold of a file, we can start accessing all its exports and figure out which one are functions and start checking on their arguments.
[00:04:54] At some point today, I got a question about JSDoc tags. I think you asked it, Chase, where you wondered is this part of what the TypeScript is parsing or is it VS Code just adding it to a tool type? It turns out TypeScript understand these JSDoc tags, so here's our value.
[00:05:15] It's got a method called getjsDocTags and the rest of this is just getting it into a form where we can easily see it in the console,
>> Mike North: And there we go. So these correspond to the comments in that code. Let me open up the code just so we can compare what's being logged out, there you go.
[00:05:42] There's another way, like property we could access to see this string up here. But this looks a lot like what we're logging out on the bottom. So if you were interested in checking your code to make sure that nobody's accessing this old version of some library or if you wanted to make sure that nobody's, you wanted to build a custom linting rule of some sort, where you need to understand how all of this code is assembled together.