Pro Members Only

This lesson is available if you have an active subscription.

Alternatively, some member might be able to gift it to you.

If you already have a subscription, you can sign in.

👈🏻

AUTOPLAY

Track Progress

Questions / Comments ==>

Advanced TypeScript Lessons

1.Introduction

free

⏱️ 0:27

2.Autocomplete Literal Unions

⏱️ 2:39

3.Compute / Resolve / Beautify

free

⏱️ 1:39

4.Dealing With Temporal Uncertainty

⏱️ 2:58

5.Generic Type vs Type For Generic

⏱️ 3:56

6.Type Inference Core Principles

⏱️ 3:42

7.Nominal Types vs Structural Types // Creating Opaque Types

⏱️ 3:33

8.Controlling Inference with Satisfies

⏱️ 2:30

9.Infer Arrays as Tuples

⏱️ 3:30

10.const enums are Awesome

⏱️ 2:59

11.Generic Inference

⏱️ 2:05

12.Generic Primitive Inference

⏱️ 2:10

13.TypeScript NoInfer Utility and Generic Inference

⏱️ 3:43

14.Using Enums as Flags

⏱️ 5:38

15.object Type to Exclude Primitives

⏱️ 2:35

16.NodeJS Native Support For TypeScript

⏱️ 1:49

NodeJS Native Support For TypeScript

Subscription Required

You must have an active subscription to access this content.
If you already have a subscription, you can sign in.

Native NodeJS Support for TypeScript

The following code will not execute natively in NodeJS 22 and below. Reason is that NodeJS cannot handle type information syntax e.g. :string.

function log(message: string) {
  console.log(message);
}

log('Native NodeJS Support!');

However it will work in node 23 and above.

nvm use 23

Type Syntax Only

Even in node 23+, features of TypeScript that require JavaScript code generation e.g. enum will not work. For example the following will not work:

enum LoginMode {
  app,
  email,
  social,
}

Fortunately, you can get TypeScript to error out at compile time for such syntax by enabling "erasableSyntaxOnly": true in your tsconfig.json's compilerOptions.

Additional Tips

Most features that are impacted aren't things that modern TypeScript developers use anyways (e.g. enums, namespaces etc.).

For example, instead of an enum you can use a simple literal type union:

type LoginMode = 'app' | 'email' | 'social';

Enjoy free content straight from your inbox 💌

Transcript

00:00

Node GS now supports TypeScript natively without any flags as long as you only use iris syntax. And what is Iris syntax? Well, you don't need to memorize it. As you can tell TypeScript to warn you if you use anything that a node will not be able to execute natively. As an example, before node GS 23, if a type annotation exists within our code, for example, here we are annotating message to be of type string and try to execute it through node. We get an error because node js, of course, does not understand type annotations. However, if you move over to node JS 23 and above and execute the same code, it executes flawlessly.

00:35

It'll warn you that this feature is experimental, but over time, this warning will go away. There is a limitation of this feature. It only supports type stripping and doesn't support features that require code generation. As an example, if you use an A number within type script, which is something that doesn't exist natively within JavaScript, and therefore would require code generation and try to execute it through node, node will error out. And this is not the only syntax that exists within TypeScript that is not native to JavaScript. Another example would be namespace. Fortunately, these aren't even features

01:07

that TypeScript developers use anymore. However, it would be great if we would get an error from TypeScript instead of it erroring out at execution With no JS for this, there is a flag within TypeScript 5.8 and above, which is I reasonable syntax only, which we can enable within the compiler options of our Ts config. Once this is enabled, you can see that now we are getting an error at compile time from TypeScript. That is, Innu is not something that is supported in Iris syntax only, so we can fix our code at compal time. For example, the alternative that most developers use instead

01:38

of INS is simply a literal string union and now we don't get any error from TypeScript. And similarly, node JS is happy to execute this code as well.