Starting with TypeScript
Tags: typescript, tutorial, beginners
Published: 2020-05-17 13:11:48


It all started with a conversation between my friend [Narendran](https://twitter.com/naren_dev_) and I. Then, it became a twitter thread🧵.

 {% twitter 1260885187828695041 %} 

Now, it’s time to put code out to back those points. If you’ve been interested in TypeScript but haven’t found the time to deep your toes into the water, or you simply didn’t figure it out how to start, or even so: it’s hard to convince your teammates of the tradeoffs. This post is for you!!

In 4 easy-to-follow tips, I’ll remove all blockers you may have for adopting TypeScript. I’ll help you get confident with it and take out the fear of getting started. Ready? Don’t blink or you might miss it!! 😎


## 1. TypeScript without TypeScript

The title sounds controversial, I wanted to hook you up (🎣). It’s actually quite straightforward and simple.

TypeScript is compiled with `tsc` (TypeScript Compiler), and the CLI accepts a few configurations. One of them enables `tsc` to compile also JavaScript, that’s extremely useful for mixed codebases (third party stuff, migration stuff, etc). But it has an additional benefit which I don’t see getting much attention.

When you allow your TypeScript Compiler to read/parse your JavaScript code, it also checks its types.

### But, how? 🦆

The answer for that is **Duck Typing**, you can skip this section if you’re familiar with the term.

> If it walks like duck, talks like a duck, quacks like a duck. Then it must be a duck!

TypeScript compiler is able to **infer** a great amount of types straight from your code, saving you the time to annotate them. Those are the types your JavaScript can be checked against. So, it’s not as complete as full-fledged TypeScript, but it gives you a good start to progressively adopt the language is your familiarity and comfort grow.

### Adding the proper config

I believe it goes without saying that you still need to have `typescript` in your machine for this approach to work. Even if you’re not using the `.ts(x)` extensions, the compiler still needs to come from somewhere.

Create in the root of your project a `tsconfig.json`. The bare minimum config you need to have is:

```json
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["es2019", "dom"]
  }
}
```

Copy paste this and you’re good to go for some client-side code. 

> ❗️Note:
> I recommend using it with [parcel](https://parceljs.org/), it’s a zero-config, very fast bundler. It takes a bunch of the annoying best practices automation from your hands and allow you to focus on what matters: your app. Perfect for small projects (and perhaps even some big ones).

## 2. `any` can be a friend

The first commandment of TypeScript is:

> Thou shall not use of `any`

But in all honesty, I don’t really think this applies to beginners (or even in some advanced cases. Let’s save that for a future post, though).

Why is `any` so terrible?

`any` is a type value, as you may have assumed: it says that *any type value* can be assigned to that given key. So, whenever you use `any`, you’re buying your way out of TypeScript. No more warnings, everything goes. And that’s bad if you look at the specific unit your working on, but it’s even worse if you look at the broad perspective.

An application is as reliable as its least reliable piece. So, a single use of `any` can compromise type-safety for your entire app. Be aware of that.

So, why the heck should I use it?

For once: *can* compromise. For numerous possible reasons, sometimes we are confronted with types that are really (really!) hard to declare. These types will eat your time and motivation up if you’re just starting. No one enjoys having a broken build for hours when you know your code works. In these cases, slap an `any` there, get your task done and come back later with a fresh head.

In a nutshell: use `any`, but accepts it’s a *technical debt* for any (pun intended) TypeScript codebase, and be sure to proper evaluate the risk before shipping code to production like that.

## 3. Pick only the right battles

This section is actually a follow-up from the previous. But integration is a beast of its own (*in my opinion*) when it comes to TypeScript. Strong-typing code you have no control over is specially tough. Nowadays, many many libraries and frameworks are migrating (or already have) their core to TypeScript. Which is awesome, simply by adding TS to your project you get autocompletion and self-documenting as a big welcome gift.

{% twitter 1260888049958838272 %}


But in other cases, you may want to refrain from that and strong-type your own code first. Which also smoothly brings us to the last point.

## 4. Community has your back

As I mentioned above, many frameworks and libraries have migrated their code to TypeScript. What about the ones which didn’t?

No worries, you won’t need to single-handedly strong-type your dependencies in order to migrate fully into TypeScript. 😅

[DefinitelyTyped](http://definitelytyped.org/) is an open-source repository maintained by the community with virtually every type you may need for other open-sourced projects. You’re a few npm searches away from strong-typing your dependencies.

Seriously! Community 👏 has 👏 your 👏 back!!

## 5. Bonus

If you want another gentle nudge into getting started with TypeScript, [Scope Leak](https://atila.io/scopeleak) has a playlist called Simplified TypeScript where I take more complex aspects of TypeScript and simplify them in byte-sized videos for you to hit the ground running!

Really, 5 minutes tops, give it a try!! 🔥

{% youtube MtK0pLS0ypo %}

I’m eager for feedback and suggestions for the next videos!!

## Wrapping up

Which other tips and tricks would suggest someone who’s about to adopt TypeScript in either a new or existing project? Have I forgot anything?

Did you use any of the tips above? How did it work for you?

Let me know in the comments or reach out on twitter [@AtilaFassina](https://twitter.com/atilafassina)

--- 

[Cover picture by James Lee](https://unsplash.com/photos/wmw4iuN9pmc)