TypeScript – Page 2 – Man With Code

Learn TypeScript #2, The Basics of How Types Work Pt. 2

Transcript:

Alright! Hello everybody! This video is a continuation of the previous video on basic types in TypeScript. Today we’re going to go over null, undefined, using types with functions, and a few other things. If you missed the previous video, you might want to go back and watch it before you start this one.

There was one thing I wanted to clarify from the last video. I mentioned that I strongly recommended against using the “any” type unless you absolutely had to, and I wanted to explain why. The basic reason, is that when you use the “any” type, you’re opting out of nearly all the checks that TypeScript is going to do for you, so if you’re going to use “any” everywhere, you might as well not use TypeScript.

I know when I first started with TypeScript, I often found myself reaching for the “any” type, but 99 times out of 100 it wasn’t because I needed it, but because I was being too lazy to stop and think about what the type of something should be.

If you take those few seconds to stop and think, you’ll end up with a program that’s better designed, you’ll have code that’s easier to come back to and change later, and you’ll have TypeScript helping you catch errors later on down the road.

Enough about “any”, let’s talk about null and undefined. This is definitely one of the more confusing parts of JavaScript (and therefore TypeScript), so let’s talk a little bit about what null and undefined are.

You may be familiar with null from other programming languages, and the easiest way I find to think about null is that it represents the explicit lack of any value. To use our player object example, if there’s no player 2, it’s possible that we’d want our player2 variable to be null.

Undefined is very similar, as it also represents the lack of any value. The key difference here, is that any variable you never assign any value to is going to hold undefined by default (though you could also explicitly set a variable to undefined, like you can set one to null).

Generally, I see null as representing a value that is intentionally missing for whatever reason. Whereas when undefined crops up in a program, it’s often a mistake or accident rather than intentional, since it implys that somebody created a variable, but then never used it. Due to this, I recommend that if you need to indicate a lack of some value, use null rather than undefined, since it will be clearer to people interacting with your code that this was probably something intentional.

All that aside, how do we use null and undefined in our TypeScript programs?

You’ll remember from our last video that we could use “null” as a type just like string or boolean or anything else, and the same is true for undefined.

Notice that if we create a variable and don’t assign to it before we try to use it, TypeScript helpfully gives us an error.

Note also that even though variables default to undefined, we can’t actually assign the value undefined or null without specifying it as part of the type of our variable.

You’ll see we get the error “type undefined is not assignable to type string”.

We have to explicitly list it as a possible type in order for TypeScript to accept it.

You’ll see also that if we try to use this variable without checking wether the type is actually not null or undefined, TypeScript will give us an error as well, preventing us from making a common mistake where we assume a variable has been assigned some value, when really it could just as easily be null or undefined.

Now, it’s important to note that TypeScript actually has a mode where it will be less strict about the usage of null and undefined. If we open up tsconfig.json and scroll down a little bit, you’ll see that I have strict mode enabled. This enables all of the strict checks listed below it, but the one that is most relevant to us is “strictNullChecks”.

If we disable strictNullChecks, or if we disable all of the stricter checks, then TypeScript will become more lenient on us and allow us to set any variable to null or undefined.

Generally I recommend against taking the more lenient route, because it leads to a lot of potential errors where you assume something will have a proper value when it actually doesn’t. It’s much better to explicitly document using the type system that a value might be null or undefined so that the proper checks can be made.

The main case for disabling strictNullChecks is if you’re converting a large existing JavaScript project over to TypeScript and you don’t want to have to deal with all the errors TypeScript starts throwing about not checking for null or undefined, since it’s common for JavaScript developers to be more wonton about their use of null and undefined. You can still get a lot of benefits out of TypeScript without enabling strictNullChecks, but again, I recommend that you enable it.

Alright, enough of that. So far we’ve been defining a number of top-level variables, but your functions will need to have types as well in order to indicate the types of arguments they accept, and what values they return.

As an example, let’s create a super simple function that tests whether a given number is a magical number.

We’ll say that if the number we pass in is 5, then it’s a magical number, otherwise it’s not magical.

And you’ll see TypeScript is complaining at me here, saying “parameter num implicitly has type any”, which is a fancy way of saying I haven’t told it what type num is, so it is forced to assume that it could be anything.

We can remedy this using syntax identical to what we used above. After the variable name, I’ll simply put a colon and the type of the variable, which is number, and now TypeScript is happy with us again.

Not only is TypeScript happy with us, but if we go to use this function, our text editor can use the definition to display what the expected types of the function arguments are.

Another thing you can do is explictly specify what the return type of your function should be. We do this in nearly the same way as declaring variables, by placing a colon after the closing parenthesis and then the type.

So, for example, if we were like hey we should have been returning a boolean, we can specify that, and then TypeScript will let us know anywhere that we are returning the wrong value.

In general as I have said before, TypeScript is going to be really good at inferring what the types of things are. So, here we could have gotten rid of the return type and TypeScript would’ve correctly guessed that boolean was what we wanted.

However, I recommend you always type your arguments in your return values for functions, that way it’s really clear to you and your team members that the function is operating in the way you intended it to operate. And it’s really easy to just glance at the line of code where you create the function and get an idea of what you expect it to do.

One other type I wanted to mention that is related to functions is called the never type.

It’s an peculiar type that means a function will never return. The two main examples of this are functions that you call to throw an error, or functions that create an infinite loop.

For example, something you’ll see in many code bases is is a function named “fail” or “panic” or something similar. This is the function you call when things have gone horribly wrong and you need to log an error and end the program.

Since the program dies before the function fully finishes, the never type is very appropriate. It’s never going to return. You can indicate that this is the case for a particular function by specifying “never” as the return type.

Likewise, if you have a function containing an infinite loop, that will also have a return value of never. The loop never stops, so the function will never return.

Keep in mind that “never” is distinct from a function that returns no value at all. For example, many times when you’re working with graphics for a game or something else, you’ll have some code that updates those graphics on-screen. There isn’t much information this code needs to return anywhere, so it’ll successfully successfully draw the graphics, and then return nothing. For that case, TypeScript has a “void” type, which you can use to indicate that the function will return at some point, but it’s not going to return any value.

That’s it for how to use basic types, and that wraps up this video.

If you’ve enjoyed what you learned here, you might like the TypeScript course that I’m working on. Head on over to https://typescriptbyexample.com, and you can put your email address in a the bottom of the page to be notified when it’s ready.

Thanks so much for watching! See you in the next video.

Learn TypeScript #1, The Basics of How Types Work Pt. 1

Transcript:

Alright! Hello everybody! Today I wanted to go over the very basics of how types work in TypeScript so that you can start using them in the programs you write. If you don’t have TypeScript installed, please see my prior videos where I’ll show you how to do that.

I’ve started here with an empty folder in VSCode, feel free to use any text editor of your choice as you follow along. Before we get started, we’re going to open up a terminal and create a TypeScript configuration file by running “tsc –init”

We’ll change one line for now, we’ll uncomment “lib” and add “dom” and “es5”. This will let us reference objects that exist when running JavaScript in a web browser, which I’ll be using for examples later.

Now let’s create our main.ts file where we’ll be doing everything today.

And then we’re going to go to Terminal and click Run Task and do “tsc –watch” to get TypeScript compiling our files.

We’re going to start off by specifying types on simple variables. There are three ways to declare variables in TypeScript and JavaScript: var, let, and const. In terms of specifying types, they all work the same, so for this video I’ll simply be using “let”. In a future video I’ll cover the differences between var, let, and const, but like I said, for this video, it doesn’t matter.

The first thing I want to touch on before we go much further is that TypeScript is really good at figuring out what the types of things are supposed to be without you needing to explicitly declare it.

For example, you can see here in Visual Studio Code we can figure out what the type of something is by hovering our mouse over, and we see that it pops up what it knows about this variable. It says “bar: number” which means it’s already figured out that this variable is a number!

However, you’ll often want to explicitly tell TypeScript what the type of something is, so that’s what we’ll be focusing on in this video. Now, as it turns out, that same syntax VS Code showed is what you’ll use to explicitly tell TypeScript what the type of something is.

We can say here “let bar: number”, and TypeScript will start enforcing that this variable can only ever be a number.

You’ll see if we try to change the value to something else, we’ll get a red underline, an error listed below, that this string is not assignable to type number.

And, just to be clear, if we remove the “: number”, we still get the same error, because TypeScript is going to assume that once you assign a variable a value of one type, that it was probably a mistake to use any other type.

Let’s start with the what the most basic types are in TypeScript: booleans, numbers, and strings.

A boolean can be either true or false.

A number can be any number you like.

And a string can be any text that you like.

Building on top of the basic types, we can do arrays of things by specifying the type and then writing an opening and closing square bracket.

There is an alternate syntax for writing arrays, though generally I don’t see it used as often. Instead of using the square brackets, you write Array, an angle bracket, the type contained in the array, and then a closing angle bracket. This is completely the same as the other syntax used above, and like I said, this is used much less commonly so I say default to the first way unless you have a good reason to do otherwise.

There’s also a variation on arrays called a tuple. If you’re not familiar with the term, you can think of it simply as an array with a fixed number of elements.

Say there are two pieces of data you always want to store next to each other, but don’t want to use a full object for whatever reason, you could do that with a tuple. For example, we could store student test scores as a tuple containing their name and the score.

Here, Tom has a score of 97.5.

And and you can see this is expecting just a string and a number. If we tried to add something extra to this, it’s going to complain to us that we’ve created something that’s not the size that we said it would be or if we try to remove a required element TypeScript will also complain. And similarly if we use the wrong type it’ll complain as well.

To be clear, you can have an array of tuples by combining the same syntaxes we’ve just learned. So we’ll have our tuple type followed by the opening and closing square brackets.

And then we would fill it out like so, and TypeScript will enforce that all the types we use here are correct.

Declaring our own objects is done in a very similar way to arrays. Let’s say we’re making a game, and we have a player with an x position, a y position, and some health. How would we do this in TypeScript?

We’ll start by declaring our player variable, then doing a colon and some curly brackets, and inside the curly brackets we can put the names and types of the fields we want to create. You’ll see that this looks very much like the actual object value that we’ll assign to the player object.

If we accidentally put in the wrong type, or if we add a field that doesn’t exist as part of the definition, TypeScript will complain at us.

It’ll often be the case that you’ll want to re-use object definitions like this in multiple places, say if you had multiple players or various functions that manipulated player objects.

There are two ways of doing this, the first and most direct way is to use the “type” keyword to define a new name that is equal to the type we defined for players earlier.

Then we can use that name in place of the full object definition for the player.

Another option with very similar effects is to create an interface. You can do this by using the “interface” keyword followed by the name you want, and then describe the types of the fields for the object like we did earlier. We can use it as the type for our player in exactly the same way that we used the definition created by the “type” keyword.

When is it appropriate to use “type” instead of “interface”? The answer is a bit too long for this video, so stay tuned for a future one where I’ll cover that. For now, just use whichever one you feel most comfortable with.

Now, going back to our example, you can see that I can now create a second player using the same type.

And if I update the definition of the type, TypeScript will helpfully give us an error on both of them, indicating that they need to be updated to match the changes.

This feedback loop is super common in development. You’ll often notice some object needs a new field, or needs that field altered in some way. You can make that change in the central type definition, and then go through and fix each of the places where TypeScript indicates that there’s a problem. No need to worry about whether you updated every spot or not, TypeScript will let you know.

Now is a good time to mention that in the same that way we created and used our own types above, we can use existing types that are part of JavaScript or JavaScript’s environment. For example, because we included “dom” in our “lib” in tsconfig.json, we can create a variable and declare that it’s type is HTMLElement. We could then fill this variable with something from the DOM API, like document.getElementById.

Now, you’ll see here that TypeScript is complaining about our HTMLElement variable. Why is it doing that? Well, if we hover over document.getElementById, we’ll see that the type is actually “HTMLElement | null”, the pipe character there means “or”. That’s because if we specify an ID that doesn’t exist on the page, this function will return null.

Using the pipe character to join multiple types together creates what’s called a “union type”, which is simply a fancy way of saying “this variable could be a few different things”. There’s a lot more to union types, and other related features in TypeScript that we’ll cover in a future video, for now, just be aware that if you have a variable that could be a couple different types, you can list those types by separating them with the pipe character.

Okay, so that covers the basics of builtin types and defining our own types. There’s a couple of catch-all types that I want to show you.

The first one is an “object”, and that represents anything that isn’t a basic type. So it’ll be anything that isn’t a boolean or a number or a string. For example, it could be HTMLElement or our Player type, or anything else. This is a type that I don’t see used all that often, because generally you either know what the object type is, or you use the even more general “any” keyword.

“any” is exactly what it sounds like. If you say the type of your variable is “any”, you’re saything that it can hold any value possible. Generally if you’re using TypeScript, I strongly recommend against reaching for “any” unless you absolutely have to use it. Though if you’re interacting with non-TypeScript code, it can be appropriate to use “any” in order to deal with JavaScript libraries that truly can produce any value.

Next up is talking about how to handle null, undefined, and how to use types with function definitions, but this video is already running a little long, so stay tuned for part 2 of this video.

If you’re enjoying what you’re learning here, you might like the TypeScript course that I’m working on. Head on over to https://typescriptbyexample.com, and you can put your email address in the form at the bottom of the page to be notified when it’s ready.

Thank you so much for watching. I’ll see you in the next video.

What is TypeScript?

Transcript:

So what is TypeScript?

At a super high level TypeScript is JavaScript with static type checking. What that really means is that you no longer have to write JavaScript code purely based on faith and good guesses that the variables and objects you’re using are what you think they are.

TypeScript is going to come along side you and enforce that “hey this is a string this is a number this is you know some object with a certain felds” TypeScript is going to add those guarantees so that you can code with more confidence.

In practice you’ll find that you’ll have fewer dumb errors; If you’re working on a team, it becomes vastly easier to communicate what certain code does because they can see right there what the types are and when they go to use them TypeScript is going to tell them if they’re using them erroneously.

It is easier to communicate with your future self so that when you come back to your code it’s easier to tell how things work. You can just look and see what the types of various objects are without having to go back and actually run the program to see if the guesses you’re making about the program are actually true.

In short, the code has become much more self-documenting

If you go to the TypeScript website you’ll see Microsoft describes TypeScript as “JavaScript that scales”. What does that really mean?

What it has meant in my experience is that you can bring a team of people together or you can work on something yourself and you can build programs and applications that very large and complex and you’ll going to have much more confidence in what your building and in and how you’re managing the complexity then you would be if it was just plain JavaScript.

I can recall numerous times on plain JavaScript projects before we started using TypeScript that I would go to refactor something or move some code around or change some logic or whatever and I could never be entirely sure that I hadn’t broken something. Even if my tests pass even if in my manual testing everything was working right, I was never able to be fully confident in the changes I had made. It seems like there would always be something flew under the radar that got missed.With TypeScript that happens far far less often, in fact I’d say almost never.

TypeScript is a strict superset of JavaScript. What that means is that anything you know about JavaScript you can transfer into your knowledge of TypeScript. There are definitely new things to learn, but it’s not a whole new world that you’ll be completely lost and confused in. If you already know JavaScript, you’ll be good to go.

In a lot of cases you can take code that you’ve already written in JavaScript change the file extension from .js to .ts and everything will work, or most of it will work with maybe a few extra type annotations that you need to add in. So it’s very straightforward to get started and to jump in.

Another great thing about TypeScript is that it compiles directly to JavaScript. In practice that means that you don’t have to install any extra runtime or ship any additional library to your users in order to start using TypeScript in your application. In development, you’ll just run the TypeScript compiler and then away you go.

Since it’s just plain JavaScript you can use the same debugging tools that you’re already used to. You can also graudually introduce TypeScript into an existing JavaScript project, slowly converting files to TypeScript bit by bit as you go along.

If you’ve used other languages that compile to JavaScript, you might be used to the compiled code looking unintelligible, very much like a machine wrote it. In most caess, TypeScript is merely erasing your type annotations, so your original code remains. In cases where it does have to manipulate things, I’ve found it makes very readable choices about the code it produces.

Anothing great thing about TypeScript too is that it supports many of the new features that have been added to JavaScript in ES6 and other newer JavaScript versions. Not only that, but you can have TypeScript compile to older JavaScript versions so that you can use the latest features in TypeScript, but still support older browsers.

One thing I wanted to mention as well is that the types are in a lot of cases optional, or what you might call a gradual, or can be inferred by TypeScript. That means there’s a lot of cases where you don’t really need to tell it what the type of something is, it’ll see “hey I’m setting this variable to a string so that must be a string”, and you don’t have to do the redundant typings that you might have gotten used to if you came from a C# for a Java background, and that’s really nice.

Also, depending on the configuration flags you set and how much you use the catch-all “any” type, you can use the type checking as much or as little as you want. If you want it to be super strict and have types everywhere, you can, or if you want to write JavaScript in the more dynamic untyped way that you’re used to, you totally can.

I think TypeScript helps enforce some good habits in a few different ways. First, once you get used to the typings, it becomes very natural when writing new code to sketch out the interfaces and relationships between data before you start writing code, because you can use those right away when you start actually implementing your program, rather than just leaving them as inert comments or notes or thoughts in your head.

Second, depending on how you configure TypeScript you can make it so it’s much more strict about checking for null and undefined, which is a really good habit to get into.I’ve been guilty myself of getting lazy and thinking “well this could fail as null or undefined, but I’m just going to ignore it because it makes my code a lot simpler.” But if TypeScript is yelling at me I’m much more likely to do the proper thing and that’s really good.

Third, if you’re defining a type and it becomes hard to think about or it hard to describe a lot of times that’s been an indication to me that “hey I’m making this more complicated than it needs to be” or I’m I’m trying to do this in a way that might be clever now but it isn’t going to stand up to the test of time. I’m going to come back to this later be super confused or I’m going to have to hand this off to a co-worker and they’re going to be super confused.

Better IDE support is one thing that’s great is if you’re using something like Visual Studio Code or JetBrains WebStorm or any other IDE or Smart Text Editor with TypeScript. You get way better auto completion so you can access things or call functions and it’s going to tell you “hey this is how you call this thing” or “hey that’s an error you missed a parameter here” and that kind of thing.

If you’ve used just plain JavaScript in the past, you’ll know that IDEs can be pretty good about guessing what things might be, but there’s a lot of times where you’ll start typing a piece of code and it does the auto-completion and gives you every possible field name that I’ve defined in my project as an option. Which is massively unhelpful. With TypeScript you avoid that issue entirely, since it knows what the types of things are, you get vastly better auto completion support. Which makes you a much happier and more productive programmer.

So that’s a general overview of what TypeScript is. I hope that was helpful to you! I’ve got other videos out there on TypeScript, so if you want to learn more, please check them out!

If you visit https://typescriptbyexample.com you’ll see some info on a course that I’m building for TypeScript. You can put your email address in at the bottom of the page and you’ll be notified when that’s ready. I’d love to hear from you, and I’d love to have you be a part of the course. Thank you so much for watching! Goodbye!

How to Install TypeScript on Linux

Transcript:

Alright! Hello everybody! So, I wanted to show you how to install TypeScript on Linux. Before we get started, a word of caution. Every Linux distribution is a little bit different, in theory everything I show you here should work across most distributions, but it’s possible that yours might do something a little different. For reference, I’m using Ubuntu 18.04.1 LTS release for this video.

One thing I want to point out before I get started is that most Linux distributions have some sort of package management system that you may be able to use to install TypeScript. For example, Ubuntu offers the node-typescript package, which you can install via apt.

The problem is that these package managers often contain old versions of TypeScript, and TypeScript releases quite frequently, so today I’m going to be showing you how to install TypeScript directly from the source so you can be running the latest and greatest version.

So, to get started we’re going to open up whatever your favorite browser is, or whatever browser you have installed. Here I’m going to be using Firefox.

We are going to head over to https://nodejs.org Now, you’ll see a page like this. It’ll give you a couple of different download options and you can opt for either the LTS or the current release.

Either one of those works. I’m going to say go for the LTS version. That’s because that stands for long-term support, so this is the version that’s going to keep getting security updates and things like that.

That’s probably the one you’ll want to go with. If you want to be on the bleeding edge, and have the latest and greatest feel free to go with the other one, it will work just as well.

For this video I’m going to go with 10.15.1. Very likely if you’re watching this at any point in the future these version numbers are going to be different. Node.js does a lot of releases so, it’s totally okay if you’re on a later version than I am. Everything should work just as well.

Download it.

Alright, it has finished downloading, so let’s open a Terminal and extract the files and get started.

Here I’ve opened the default Terminal that comes with Ubuntu. We’re going to do:

cd Downloads

to get to our downloads folder.

We’re then going to type:

tar xvf node-v10.15.1-linux-x64.tar.xz

Hit enter. It’ll print out the files it unzipped and then we should be able to see the new folder.

Next we need to add Node.js to our PATH. We can do this by typing:

export PATH=~/Downloads/node-v10.15.1-linux-x64/bin:$PATH

Now that Node.js is on our PATH, we can test if Node.js is installed properly by typing:

node

and hitting enter.

And this little angle bracket should appear. And we can start entering JavaScript code here.

So, two plus two is four. Let’s see, we could do a setTimeout. So in 5 seconds that should display something. There it is.

If you want to get out of here just hit CTRL+C. Twice. And then you’re back on the normal Terminal prompt.

In order to use Node.js and TypeScript in future Terminal sessions, we’ll need to put that PATH line at the end of your .bashrc or .bash_profile file, or whatever profile file your shell of choice uses if you’re not on bash. To do that I’m going to open up Ubuntu’s default text editor.

We’ll hit open, and navigate to our home directory. Note that you’ll need to ensure that hidden files are showing. I can do that here by pressing CTRL+H. I’ll open .bashrc, copy that line from before, paste it to the bottom, and then save the file. And then, hey presto, any subsequent Terminals we open will have Node.js available to us.

So, all that out of the way, let’s install TypeScript! In order to install TypeScript we’re going to use something called npm. If you’re unfamiliar with npm that stands for the node package manager and that’s how lots of different Node.js based libraries and programs are distributed, TypeScript among them.

How do we use npm to install it? Well, here in this Terminal we’re going to type:

npm install --global typescript

And hit enter.

Note that if you’ve installed Node.js and npm from your package manager, you may need to prefix the previous command with sudo to run it with root priviledges

And you’ll see here it says added one package from one contributor in 1 second.

Now it’s very likely that you’ll see a different version number here. TypeScript also like Node.js releases fairly frequently. TypeScript is really good about backwards compatibility, so you shouldn’t have to worry about anything you see in this video or any later video being incompatible.

If you wanted to be on the exact version that I am going to show you, though, what you can do is go back to the Terminal and run:

npm uninstall --global typescript

to get rid of what we just installed.

And we’ll then run a command similar to what we did before:

npm install --global typescript@3.3.3

When you add that @ sign and then the version number, it’s going to guarantee that that’s the version you’re going to install rather than whatever the latest is (which is the default).

There we go. We’ve got that working.

So now what I’m going to do is create a new folder on the desktop. We’re going to call it “test” and we’re just going to see if TypeScript is working.

Let’s open up “test”.

We’re going navigate our Terminal to this new folder as well. You can do this by typing:

cd ~/Desktop/test

Once you’ve done that we’re going to create a file named main.ts. All TypeScript files end in .ts.

You can do this by entering the comand:

touch main.ts

You’ll see the file appears in the folder.

Now let’s put something in this main.ts file for TypeScript to compile. So, we’re going to open up the default text editor that comes with Ubuntu. If you have a particular text editor that you prefer, feel free to use it.

I’m going to go to Open and find main.ts in the folder on my Desktop.

And then we’ll put in the simplest possible “Hello, World!” program and save it.

console.log("Hello, World!");

Now in order for TypeScript to compile our “Hello, World!” program it needs a configuration file.

We can create the default one by going back to our Terminal and running:

 tsc --init

When we hit enter, it’s going to create that file for us. So, you can see this tsconfig.json file has been created.

Don’t worry too much about that file I will be creating a video explaining exactly what it is, why we use it, how to use it, what the different options inside it mean for now all we need to know is that we need it there and now we have it.

And to get TypeScript to compile our main.ts file, just run:

tsc

and hit enter. It will find all the TypeScript files in this folder and compile them. You see we now have a main.js file.

We’ll run that main.js file through Node.js:

node main.js

And see we’ve got “Hello, world!”

Awesome! Exactly what we wanted.

So everything’s working. If you’re seeing the same thing, hey you’re good to go, you’ve got TypeScript installed.

There is one other thing I wanted to show you: You can have TypeScript watch for changes, rather than having to rerun it each time you change something. So, what we’re going to do is do is go back to our Terminal and enter:

tsc --watch

See it gives us a little message “starting compilation in watch mode”.

And then I’m going to go back to our file and say “Hello World! Again!” and I’m going to save it. And you see that flashed a bit. It said “file change detected”, “0 errors”.

We’re going to open up another Terminal and do the same:

cd ~/Desktop/test"

that we did before.

You can see if we run our main.js, hey! It says “Hello World! Again!” just like we wanted.

One thing that’s really nice about this is that if you make a mistake, here I’m going to forget to have the closing parenthesis and semicolon, if we save this TypeScript is going to give us an error and say “hey! I expected a closing parenthesis here!”

So we can add that back in and save it and everything’s happy again.

Very cool! That’s it! You’ve got TypeScript installed!

By the way if you’re interested in going deep into learning TypeScript I’ve got this TypeScript by Example course that I’m working on now. You can head on over to https://typescriptbyexample.com Scroll down to the bottom, and you can put in your email address to be notified when the course is released. Also, stay tuned to this YouTube channel for future updates. Thank you so much for watching!

How to Install TypeScript on macOS

Transcript:

Alright! Hello everybody!

So, I wanted to show you how to install TypeScript on macOS.

So, first things first we’re going to open up whatever your favorite browser is, or whatever browser you have installed. Here I’m going to be using Safari.

We are going to head over to https://nodejs.org

Now, you’ll see a page like this. It’ll give you a couple of different download options and you can opt for either the LTS or the current release.

That’s probably the one you want to go with.

If you want to be on the bleeding edge, and have the latest and greatest feel free to go with the other one, it will work just as well. For this video I’m going to go with 10.15.1.

Very likely if you’re watching this at any point in the future these version numbers are going to be different. Node.js does a lot of releases so, it’s totally okay if you’re on a later version than I am. Everything should work just as well.

Download it.

Alright, it has finished downloading, so I’m going to go to my Downloads folder and open it.

We’re just going to click through here.

We’ll hit continue.

We’ll hit continue again. It’ll prompt us to agree to the license, click agree.

It’ll take 60 megabtyes of space, that’s fine by me, hit Install.

Enter your account password at the authorization prompt and hit Install Software.

Give that a few moments. Alright, and Node.js has been installed! Hit Close.

We don’t need the installer any more, so just hit “Move to Trash” here.

So, how can we verify that things are working here?

Well, let’s go to the application search in the top-right corner of the screen and look for “Terminal”.

Here we’ve got our Terminal. The way we can test if Node.js is installed properly is to type:

node

and hit enter.

And this little angle bracket should appear.

And we can start entering JavaScript code here. So, two plus two is four. Let’s see, we could do a setTimeout. So in 5 seconds that should display something. There it is.

If you want to get out of here just hit CTRL+C. Twice.

And then you’re back on the normal Terminal prompt.

So, let’s install TypeScript.

In order to install TypeScript we’re going to use something called npm. If you’re unfamiliar with npm that stands for the node package manager and that’s how lots of different Node.js based libraries and programs are distributed, TypeScript among them.

So, how do we use npm to install it? Well, here in this Terminal we’re going to type:

sudo npm install --global typescript

And hit enter.

Enter our password. Give that a few moments to do its thing.

And you’ll see here it says added one package from one contributor in 6 seconds.

If you wanted to be on the exact version that I am going to show you, though, what you can do is go back to the Terminal and run:

sudo npm uninstall --global typescript

To get rid of what we just installed. And we’ll then run a command similar to what we did before:

sudo npm install --global typescript@3.3.3

When you add that @ sign and then the version number, it’s going to guarantee that that’s the version you’re going to install rather than whatever the latest is (which is the default).

There we go. We’ve got that working.

So now what I’m going to do is create a new folder on the desktop. We’re going to call it “test” and we’re just going to see if TypeScript is working. It’s installed but is it actually working?

Let’s open up “test”. We’re going navigate our Terminal to this new folder as well. You can do this by typing:

cd Desktop/test

Once you’ve done that we’re going to create a file named main.ts. All TypeScript files end in .ts.

You can do this by entering the comand:

touch main.ts

You’ll see the file appears in the folder.

Now let’s put something in this main.ts file for TypeScript to compile.

So, we’re going to open up TextEdit. If you have a particular text editor that you prefer, feel free to use it. TextEdit is all I’ve got on this particular machine at the moment. I’m going to go to File -> Open and find main.ts in the folder on my Desktop.

And then we’ll put in the simplest possible “Hello, World!” program and save it.

Now in order for TypeScript to compile our “Hello, World!” program it needs a configuration file.

We can create the default one by going back to our Terminal and running:

tsc --init

If we hit enter, it’s going to create that file for us. So, you can see this tsconfig.json file has been created.

And to get TypeScript to compile our main.ts file, just run:

tsc

It will find all the TypeScript files in this folder and compile them. You see we now have a main.js file.

We run that main.js file through Node.js, and see we’ve got “Hello, world!”

Awesome! Exactly what we wanted.

So everything’s working. If you’re seeing the same thing, hey you’re good to go, you’ve got TypeScript installed.

There is one other thing I wanted to show you: You can have TypeScript watch for changes, rather than having to rerun it each time you change something.

So, what we’re going to do is do is go back to our Terminal and enter:

tsc --watch

See it gives us a little message “starting compilation in watch mode”.

And then I’m going to go back to our file and say “Hello World! Again!” and I’m going to save it. And you see that flashed a bit. It said “file change detected”, “0 errors”.

We’re going to open up another Terminal and do the same “cd Desktop/test” that we did before.

You can see if we run our main.js, hey it says “Hello World! Again!” just like we wanted.

So we can add that back in and save it and everything’s happy again.

Very cool! That’s it!

You’ve got TypeScript installed!

Scroll down to the bottom, and you can put in your email address to be notified when the course is released.

Also, stay tuned to this YouTube channel for future updates. Thank you so much for watching!