js
// Accessing the property 'toLowerCase'
// on 'message' and then calling it
message.toLowerCase();
// Calling 'message'
message();

js
constmessage ="Hello World!";

txt
TypeError: message is not a function

js
functionfn(x) {
returnx.flip();
}

Static type-checking

Think back to thatTypeError we got earlier from trying to call astring as a function.Most people don’t like to get any sorts of errors when running their code - those are considered bugs!And when we write new code, we try our best to avoid introducing new bugs.

If we add just a bit of code, save our file, re-run the code, and immediately see the error, we might be able to isolate the problem quickly; but that’s not always the case.We might not have tested the feature thoroughly enough, so we might never actually run into a potential error that would be thrown!Or if we were lucky enough to witness the error, we might have ended up doing large refactorings and adding a lot of different code that we’re forced to dig through.

Ideally, we could have a tool that helps us find these bugsbefore our code runs.That’s what a static type-checker like TypeScript does.Static type systems describe the shapes and behaviors of what our values will be when we run our programs.A type-checker like TypeScript uses that information and tells us when things might be going off the rails.

ts
constmessage ="hello!";
 
message();
This expression is not callable.  Type 'String' has no call signatures.2349This expression is not callable.  Type 'String' has no call signatures.Try

Running that last sample with TypeScript will give us an error message before we run the code in the first place.

Non-exception Failures

So far we’ve been discussing certain things like runtime errors - cases where the JavaScript runtime tells us that it thinks something is nonsensical.Those cases come up becausethe ECMAScript specification has explicit instructions on how the language should behave when it runs into something unexpected.

For example, the specification says that trying to call something that isn’t callable should throw an error.Maybe that sounds like “obvious behavior”, but you could imagine that accessing a property that doesn’t exist on an object should throw an error too.Instead, JavaScript gives us different behavior and returns the valueundefined:

js
constuser = {
name:"Daniel",
age:26,
};
user.location;// returns undefined

Ultimately, a static type system has to make the call over what code should be flagged as an error in its system, even if it’s “valid” JavaScript that won’t immediately throw an error.In TypeScript, the following code produces an error aboutlocation not being defined:

ts
constuser = {
name:"Daniel",
age:26,
};
 
user.location;
Property 'location' does not exist on type '{ name: string; age: number; }'.2339Property 'location' does not exist on type '{ name: string; age: number; }'.Try

While sometimes that implies a trade-off in what you can express, the intent is to catch legitimate bugs in our programs.And TypeScript catchesa lot of legitimate bugs.

For example: typos,

ts
constannouncement ="Hello World!";
 
// How quickly can you spot the typos?
announcement.toLocaleLowercase();
announcement.toLocalLowerCase();
 
// We probably meant to write this...
announcement.toLocaleLowerCase();Try

uncalled functions,

ts
functionflipCoin() {
// Meant to be Math.random()
returnMath.random <0.5;
Operator '<' cannot be applied to types '() => number' and 'number'.2365Operator '<' cannot be applied to types '() => number' and 'number'.
}Try

or basic logic errors.

ts
constvalue =Math.random() <0.5 ?"a" :"b";
if (value !=="a") {
// ...
}elseif (value ==="b") {
This comparison appears to be unintentional because the types '"a"' and '"b"' have no overlap.2367This comparison appears to be unintentional because the types '"a"' and '"b"' have no overlap.
// Oops, unreachable
}Try

Types for Tooling

TypeScript can catch bugs when we make mistakes in our code.That’s great, but TypeScript canalso prevent us from making those mistakes in the first place.

The type-checker has information to check things like whether we’re accessing the right properties on variables and other properties.Once it has that information, it can also startsuggesting which properties you might want to use.

That means TypeScript can be leveraged for editing code too, and the core type-checker can provide error messages and code completion as you type in the editor.That’s part of what people often refer to when they talk about tooling in TypeScript.

ts
importexpressfrom"express";
constapp =express();
 
app.get("/",function (req,res) {
res.sen
         
send
sendDate
sendfile
sendFile
sendStatus
});
 
app.listen(3000);Try

TypeScript takes tooling seriously, and that goes beyond completions and errors as you type.An editor that supports TypeScript can deliver “quick fixes” to automatically fix errors, refactorings to easily re-organize code, and useful navigation features for jumping to definitions of a variable, or finding all references to a given variable.All of this is built on top of the type-checker and is fully cross-platform, so it’s likely thatyour favorite editor has TypeScript support available.

tsc, the TypeScript compiler

We’ve been talking about type-checking, but we haven’t yet used our type-checker.Let’s get acquainted with our new friendtsc, the TypeScript compiler.First we’ll need to grab it via npm.

sh
npm install -g typescript

This installs the TypeScript Compilertsc globally.You can usenpx or similar tools if you’d prefer to runtsc from a localnode_modules package instead.

Now let’s move to an empty folder and try writing our first TypeScript program:hello.ts:

ts
// Greets the world.
console.log("Hello world!");Try

Notice there are no frills here; this “hello world” program looks identical to what you’d write for a “hello world” program in JavaScript.And now let’s type-check it by running the commandtsc which was installed for us by thetypescript package.

sh
tsc hello.ts

Tada!

Wait, “tada”what exactly?We rantsc and nothing happened!Well, there were no type errors, so we didn’t get any output in our console since there was nothing to report.

But check again - we got somefile output instead.If we look in our current directory, we’ll see ahello.js file next tohello.ts.That’s the output from ourhello.ts file aftertsccompiles ortransforms it into a plain JavaScript file.And if we check the contents, we’ll see what TypeScript spits out after it processes a.ts file:

js
// Greets the world.
console.log("Hello world!");

In this case, there was very little for TypeScript to transform, so it looks identical to what we wrote.The compiler tries to emit clean readable code that looks like something a person would write.While that’s not always so easy, TypeScript indents consistently, is mindful of when our code spans across different lines of code, and tries to keep comments around.

What about if wedid introduce a type-checking error?Let’s rewritehello.ts:

ts
// This is an industrial-grade general-purpose greeter function:
functiongreet(person,date) {
console.log(`Hello${person}, today is${date}!`);
}
 
greet("Brendan");Try

If we runtsc hello.ts again, notice that we get an error on the command line!

txt
Expected 2 arguments, but got 1.

TypeScript is telling us we forgot to pass an argument to thegreet function, and rightfully so.So far we’ve only written standard JavaScript, and yet type-checking was still able to find problems with our code.Thanks TypeScript!

Emitting with Errors

One thing you might not have noticed from the last example was that ourhello.js file changed again.If we open that file up then we’ll see that the contents still basically look the same as our input file.That might be a bit surprising given the fact thattsc reported an error about our code, but this is based on one of TypeScript’s core values: much of the time,you will know better than TypeScript.

To reiterate from earlier, type-checking code limits the sorts of programs you can run, and so there’s a tradeoff on what sorts of things a type-checker finds acceptable.Most of the time that’s okay, but there are scenarios where those checks get in the way.For example, imagine yourself migrating JavaScript code over to TypeScript and introducing type-checking errors.Eventually you’ll get around to cleaning things up for the type-checker, but that original JavaScript code was already working!Why should converting it over to TypeScript stop you from running it?

So TypeScript doesn’t get in your way.Of course, over time, you may want to be a bit more defensive against mistakes, and make TypeScript act a bit more strictly.In that case, you can use thenoEmitOnError compiler option.Try changing yourhello.ts file and runningtsc with that flag:

sh
tsc --noEmitOnError hello.ts

You’ll notice thathello.js never gets updated.

Explicit Types

Up until now, we haven’t told TypeScript whatperson ordate are.Let’s edit the code to tell TypeScript thatperson is astring, and thatdate should be aDate object.We’ll also use thetoDateString() method ondate.

ts
functiongreet(person:string,date:Date) {
console.log(`Hello${person}, today is${date.toDateString()}!`);
}Try

What we did was addtype annotations onperson anddate to describe what types of valuesgreet can be called with.You can read that signature as ”greet takes aperson of typestring, and adate of typeDate“.

With this, TypeScript can tell us about other cases wheregreet might have been called incorrectly.For example…

ts
functiongreet(person:string,date:Date) {
console.log(`Hello${person}, today is${date.toDateString()}!`);
}
 
greet("Maddison",Date());
Argument of type 'string' is not assignable to parameter of type 'Date'.2345Argument of type 'string' is not assignable to parameter of type 'Date'.Try

Huh?TypeScript reported an error on our second argument, but why?

Perhaps surprisingly, callingDate() in JavaScript returns astring.On the other hand, constructing aDate withnew Date() actually gives us what we were expecting.

Anyway, we can quickly fix up the error:

ts
functiongreet(person:string,date:Date) {
console.log(`Hello${person}, today is${date.toDateString()}!`);
}
 
greet("Maddison",newDate());Try

Keep in mind, we don’t always have to write explicit type annotations.In many cases, TypeScript can even justinfer (or “figure out”) the types for us even if we omit them.

ts
letmsg ="hello there!";
let msg: stringTry

Even though we didn’t tell TypeScript thatmsg had the typestring it was able to figure that out.That’s a feature, and it’s best not to add annotations when the type system would end up inferring the same type anyway.

Note: The message bubble inside the previous code sample is what your editor would show if you had hovered over the word.

Erased Types

Let’s take a look at what happens when we compile the above functiongreet withtsc to output #"use strict";