This is Maina Wycliffe, the author of this newsletter, in case you don’t know me. As I write this, we are nearing the end of the year, about 11 days to go. I want to start by saying thank you to everyone who is subscribed to this newsletter and those who read my content from the bottom of my heart.

We have seen incredible growth this year alone, with over 2000 subscribers to this newsletter. I know this is probably not a large number, but to me, it’s the biggest I have ever been. I want to say thank you for your support, for reading my content, and for being there with me during my ups and downs.

In the latter half of the year, I haven’t been able to keep up with the content, and I want to resume that in 2025, with 2 - 3 high-quality articles every month instead of the usual weekly content, which I found hard to keep up with, and you can quickly get burned out.

That’s not the only reason I haven't been publishing regularly; over the last few months, I have been working on a Typescript Book. This has been taking up a lot of my time lately, but I am beginning to feel delighted with my progress. As we get closer to publishing it, I will release more details on the book early next year.

By reducing the number of articles to 2 to 3 per month, I aim to maintain a regular writing schedule for this newsletter while striking a balance between quality, my book, and my day job.

As we look to the future, I hope our collective journey of learning and growth will continue in 2025. I would like to take this opportunity to extend my warmest wishes to you all for a joyous holiday season and a happy new year.

Yours Truly,

Maina Wycliffe

All Things Typescript

You needed to transpile the Typescript file to Javascript or use something like ts-node to do that for you. For instance, below, I am using the tsc compiler to transpile to Javascript.

But as you can see, this can be tedious compared to something like Bun, which will execute Typescript directly.

NodeJS is adding experiment support for stripping type from Typescript files so that we can execute the Typescript code. NodeJS is introducing two new experimental flags; the first is for stripping Typescript types and is called --experimental-strip-types.

The second one is --experimental-transform-types which is to transform typescript types for types such as enums that need to be converted to Javascript equivalent.

Please note that the above is still experimental but a step in the right direction.

Previous Articles

My name is Maina Wycliffe, and I love teaching Typescript to developers. My goal is to break down complex topics into small, understandable bits that you can apply in your day-to-day life as a developer.

Subscribe now

React Advanced London 2024

I want to announce a special collaboration with GitNation, the organizers of events such as JSNation and React Summit in Amsterdam and New York, React Day Berlin, and React Advanced in London.

React Advanced London 2024 is coming up later in the year (October), and as subscribers for All Things Typescript, you will get 10% off for tickets using the code AllThingsTypescript10 for the conference.

In this conference, you learn more about React 19, Performance, Server Components, Senior-Driven Tech Mindset & more! On top of that, you will get to network and reconnect with some of the top minds in the industry and engage in board games and, if you want to, parties and karaoke.

Get your ticket today

Typescript 5.5 Released

The latest version of Typescript (version 5.5) was released in June and has a very exciting update that all Typescript developers are excited about. Typescript has improved Type inference and now can narrow Types based on control flow within arrays when you use the array filter method, which wasn’t possible before.

Before Typescript 5.5., if you filtered an array to, let’s say, remove undefined values inside an array, Typescript wasn’t able to infer that the type needed to be narrowed as the undefined values have been removed. This has changed, as demonstrated in the video clip I created below when the beta version was released.

Other notable features include:

• Control flow narrowing for Constant Indexed Accesses

• Import types into JS Docs (JS Files)

• Type-checking in regular expressions

• ESM Set new methods such as union and intersection are now supported.

And there is more, which you can learn by reading the announcement blog here.

Next week, I will take a deep dive into some of the exciting features of Typescript 5.5.

From All Things Typescript

I want to apologize for not publishing as regularly as in previous months, but I will resume publishing regularly in June, starting next week when I take a deep dive into Typescript 5.5.

I want to give a shout-out to CSS Isn’t Magic by Stas Melnikov. Most of us struggle with understanding CSS concepts, and If you want to change that and take your CSS game to the next level, please subscribe to the newsletter.

From Other Authors

How To Write API Response Types with TypeScript by Artem Holinka

Organize TypeScript types for API responses to ensure a great development experience, code maintenance, and avoidance of obvious coding errors.

Link

7 Use Cases for Javascript Proxies by Matt Lewandowski

JavaScript's Proxy object is a useful tool that opens up a world of possibilities, allowing you to create some really useful behaviors in your applications. When combined with TypeScript, Proxy enhances your ability to manage and manipulate objects and functions in ways you might not have thought possible. In this article, we'll explore the incredible utility of Proxies through practical examples.

Link

Visual testing: The greatest trick in UI development by Michael Shilman

In UI development, making sure everything looks right is as important as making sure it works. Visual tests are image snapshot tests that solve for this.

However, somewhat surprisingly, they can also replace the most brittle part of many UI unit tests: asserting on details of the UI. In many cases this can replace the unit test entirely, allowing you to test more with far less code.

Link

A Gentle Intro to TypeScript by Jo Franchetti

This article is an excellent article for developers who are just getting started with Typescript and wondering why Typescript exists and the fundamentals of Typescript.

Link

Introduction to Sorting Algorithms in JavaScript by Alex Merced

Sorting algorithms are fundamental to computer science and programming. They are essential tools for organizing data in a meaningful order, whether it’s numerical, alphabetical, or based on any other criteria. For JavaScript developers, understanding these algorithms is crucial, as they often need to manipulate and sort data efficiently within their applications. This blog aims to provide an introduction to some of the most common sorting algorithms implemented in JavaScript, highlighting their mechanics and when to use them.

Link

Dual Publishing ESM and CJS Modules with tsup and Are the Types Wrong? by John Reilly

If you need to publish a package that supports both ECMAScript modules (ESM) and CommonJS modules (CJS), you can use tsup to do so. This post will show you how to do that and how to ensure that the types are correct using the tool Are the Types Wrong?.

Link

Understanding JavaScript Object Accessors by Jack Pritom Soren

JavaScript is a versatile and powerful programming language used extensively in web development. One of its key features is the ability to define objects, which can encapsulate properties and methods. Among the various ways to interact with these objects, accessors play a crucial role. This blog post will delve into the concept of JavaScript object accessors, explaining what they are, how they work, and why they are beneficial.

Link

I've been writing TypeScript without understanding it by vincanger

The other day, I was stuck with a bug in some code that was handling optimistic updates, so I asked my colleague Filip for some help. Filip, a TypeScript wizard, mentioned that the satisfies keyword would be part of the solution I was looking for.

Satisfies? What the heck is that? And why had I never heard of it before? I mean, I’ve been using TypeScript for some time now, so I was surprised I didn’t know it myself.

Link

Subscribe now

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If this interests you, please get in touch with me to discuss it.

And until next time, please keep on learning.

What’s a Registry?

Before discussing JSR, let’s talk about what a registry is. A registry is a centralized place to find and discover 3rd-party packages. Currently, NPM is the defacto package manager for Javascript and Typescript. With millions of Javascript libraries (packages), both public and private, that you can find and use.

npm is the world's largest software registry. Open source developers from every continent use npm to share and borrow packages, and many organizations use npm to manage private development as well. - NPMJS

Using 3rd party libraries saves a lot of time during development and borrows code from other developers to help solve common problems like developing web apps, where we have a few options such as React, Angular, Vue, etc. Most of these 3rd party libraries also benefit from being open source, with multiple contributors, and being consumed by countless people, which means they are battle-tested and improved quality.

Registries such as NPMJS and UNPKG, among others, help with the discovery and easy management of packages.

What is JSR?

JSR is brought to us by Deno and is a modern package repository for Javascript and Typescript (NodeJS, Bun, Deno, etc.). It is built to be fully backward compatible with NPM. JSR aims to bring in some much-needed standards for package publishing by development.

When I watched the introduction to JSR video by Ryan Dalh (creator of both Node and Deno) at DevWorld earlier this year, the one thing that stuck with me was how he described JSR. JSR is to NPM, as Typescript is to Javascript. You can watch the whole video here; it’s worth every second.

As a package author, there are many things to consider before publishing a package. Do you choose ESModules, or CommonJS, or both? This impacts how the end user consumes your package and can be very frustrating for both the author (most of which are doing it for free) and consumers.

JSR looks to bring some much-needed enforced standardizations like ES Modules only support so that developers ship their code the way they wrote instead of compiling it before pushing it to the repository.

So, what makes JSR Different

There are a few key features that JSR prides itself on:

First-Party Typescript Support

Let’s say you have built a library you want to ship to developers via NPM. You have to transpile it to Javascript and also generate Typescript declaration files (.d.ts). This means that when you want to go to the definition for an NPM package, instead of landing on the actual code you want, you end up landing inside the Typescript declaration file. While this is useful, sometimes you want to look at the code and see the implementation details.

As you can see from the above video, when we go to the definition for the useReactTable hook, instead of landing on the package code, we end up in the Type declaration files instead.

However, by supporting Typescript out of the box, JSR encourages developers to ship Typescript code directly instead of using Javascript and Type Declaration. This has the added benefit of easy documentation generation and improved performance for your code editor. You can learn more about this here.

ESM Modules only Packages

Another key differentiator compared to NPM is that JSR doesn’t support CommonJS; it only supports ESModules - import and exports, not require syntax.

Javascript has had, for a while now, two competing module standards - ESModules and CommonJS- and I will be writing a comprehensive write-up between the two and others, as well as the journey of how we got here in the future.

Subscribe now

Compatibility with NPM

JSR is a superset of npm

Another key feature of JSR is that it is fully backward and compatible with NPM packages; you can consume both NPM and JSR packages. As a package developer, you can reference NPM packages to packages you publish to JSR. This is huge, as it means all NPM packages are available for you and aren’t limited to packages available in JSR.

This reminds me why I think BunJS is special: its compatibility with node. You don’t have to change your NodeJS code to run it with Bun. You can learn more about it in a previous issue here.

Please note: when installing a JSR package in an NPM project, JSR will transpile the Typescript project, before being installed locally (inside the node_modules directory).

Documentation Generation

JSR will generate documentation for your packages from your JS Docs automatically when you publish your packages; there is no need to maintain a separate docs site for package maintainers. You can learn more about this here.

All packages are scoped

Another key difference between JSR and NPM is that all packages are scoped; for instance, instead of just typescript, Microsoft would have to decide whether to scope it under Microsoft - @microsoft/typescript or something else. To prevent abuse, JSR has reserved some common scopes, such as Google, Microsoft, etc., that can be used maliciously if they fall into the wrong hands.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

How to get started with JSR

When I tried my hand at JSR for the first time, I was impressed by how easy it was to get started. It’s easy to start with JSR, and you can adopt it in your project today, just like with other NPM-compatible Javascript package registries.

First, once you find a package you intend to use, select your package manager - npm, pnpm, bun, deno, etc. JSR will give you the command you need to install the package in your environment, as shown below:

If you are on NPM like most developers will be, JSR will add JSR (@jsr:registry=https://npm.jsr.io) as the registry in the NPM config file (.npmrc) and then install the package inside the node_modules just like a normal NPM package.

Finally, you can consume the package just like any other NPM package in your project, and both NPM and JSR packages can be used in the same project, as shown below.

Easy, right?

Conclusion

In this issue, we looked at JSR and what makes JSR different from NPM. We looked at the key differentiators of the Javascript repository and what set it apart compared to other package managers, such as first-class support for Typescript and ES Modules packages.

On top of that, JSR looks to generate documentation for the packages published in the repository, which is fully backward compatible with NPM. You can start using it today.

That's it for this issue. Thank you for getting this far. If you enjoyed this issue and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If so, please get in touch with me to discuss it.

And until next time, please keep on learning.

My name is Maina Wycliffe, and I love teaching Typescript to developers. My goal is to break down complex topics into small, understandable bits that you can apply in your day-to-day life as a developer.

If you want to learn Typescript, please subscribe to this newsletter.

Subscribe now

Now that that self-plug is out of the way (subtle) let’s get to today’s issue.

Typescript Tip 💡

This month was thin on official Typescript news, so instead of that, I will leave you with a Typescript tip instead.

Many developers habitually reach out for type assertions when checking whether an object with a union of types has specific fields. The in-operator is perfect for this, as shown below:

From All Things Typescript

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

Book Recommendation

Learning Typescript by Josh Goldberg

This is an amazing book, especially if you are starting Typescript. It’s well laid out, and the concepts are broken down into small, easy-to-understand concepts that are easy to follow and grasp different concepts in Typescript.

You can learn more about the book here.

From Other Authors

Effective Testing in JavaScript by Ashley Davis

This article emphasizes the importance of testing, advocating for a proactive approach where testing is frequent and early, ensuring code remains functional. The author shares personal insights and techniques to make testing less laborious while still effective, ultimately underscoring the goal of delivering reliable code that meets customer needs.

Link

Automatically Generate Types for Your PostgreSQL Database by Paul Scanlon

SQL can be typesafe, in the JavaScript sense of the word. Paul Scanlon demonstrates why devs shouldn't be afraid to work with "raw SQL."

Link

The Typescript feature we all wanted by Ohans Emmanuel

Inferred Type Predicates are now available in Typescript 5.5 Beta. In this article, I’ll explain the much-awaited feature and how it’ll help you write more type-safe code.

Link

A Guide to the Node.js Event Loop by Musab Habeeb

The Node.js event loop is a crucial mechanism in Node.js that makes Node.js programs run concurrently and asynchronously. Mastering the Node.js event loop helps a Node.js developer understand how Node.js programs run under the hood.

In this article, you will learn the basics of the event loop, starting with threads and processes, then how the JavaScript event loop works, and finally, how the Node.js event loop works.

Link

How to document your JavaScript package Andy Jiang, Luca Casonato, Jo Franchetti, and Leo Kettmeir

This article emphasizes the importance of writing clear, concise JSDocs. It outlines best practices for creating JSDocs, including providing good type information, using tags to add detail, and including examples to demonstrate usage. It also discusses the significance of keeping documentation up-to-date with code changes and auditing JSDoc comments to ensure quality. The goal is to help users quickly understand how to use a package with minimal effort, enhancing the package's success within the community.

Link

Subscribe now

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If this interests you, please get in touch with me to discuss it.

And until next time, please keep on learning.

Before we go any further, let’s briefly talk about what enums are: Enums allow developers to define a list of named constants representing distinct states within their application. For instance, if you wanted to have a switch button, the values can either be on or off, and an enum is perfect to represent this state, as shown below:

And you can use the above enum, just like any type in Typescript.

To understand the difference between enums and const enums, we first need to understand their behavior after compilation before the behavior is very similar.

In the book Effective Typescript by Don Vanderkom (a strongly recommended read), the author says that typescript has no impact on Javascript runtime. This is because Types are removed during transpilation, leaving you with good old Javascript. You can learn more about this relationship in this issue, which we covered a few weeks ago.

Of course, this isn’t always the case, and Enums are one of those exceptions, with Enums getting converted into objects instead of being removed, as shown below:

So, when we pass an enum, the object that is produced during the transpilation process is referenced, as shown below.

Another thing to note about enums is that the values of each element in an Enum are numbers - incrementing from 0, from the top down, unless the first number is indicated - instead of the values we entered above, so in our case, ON would be 0 and Off would be 1. Below is a case where the initial number is indicated.

This isn’t always the desired behavior, but it can be fixed by explicitly adding the value of each element in the enum, such as having the value be a string.

Or even an expression, as shown below:

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

Const Enums

This isn’t always desired, and that's where const enums come in. They are just like regular enums, but they are prefixed by the const keyword before their declaration.

The other important difference is that const enum values get inlined instead of producing an object, taking us back to zero impact on the JS runtime, as const enums do not generate objects after transpilation.

Generally speaking, regular enums are valid solutions, but in those cases where you don’t want to pay the penalty of extra code generated by using regular enums, const enums are a very good solution, as they don’t generate any code for their support.

As you can see, no more Switch object is being created. Of course, just like with regular enums, we still have the same issue of enum element values being incremental numbers unless otherwise specified.

Conclusion

In this issue, we examined the difference between enums and const enums. Unlike regular enums, const enums don’t generate the javascript object; the code is inlined. This means that you are not paying the penalty for extra code generation that you get when using regular enums.

While this is normally not a concern for most projects, in some cases, it can have a negative impact, leading to large JS code being produced and longer build / transpilation times. This can easily be solved by using const enums, which would be easier to refactor compared to alternative solutions such as unions.

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If so, please contact me to discuss it.

And until next time, please keep on learning.

I have also covered this topic in the relationship between two libraries - Valibot and Zod- and this will be a broader look, as we can achieve this with a lot more.

Subscribe now

So, without further ado, let’s get going:

Schema-first type design?

Instead of designing our types in Typescript, this idea is to start somewhere else and then generate static types.

Typescript types, generally, represent the state of our data, defining what we expect our data to be. So, for instance, if we had a list of users, we expected to have a type describing our user with all the fields we needed for that specific user. This is the data that Typescript takes, and type checks out code against it.

The one issue with Typescript is that during the transpilation/compilation (choose your poison) process, these Types are stripped away as Typescript gets transpiled to Javascript. This also means we don’t have access to the type of definition we spent a lot of time designing at runtime.

So, if we need runtime validation, such as user input validation, we would need a different tool to achieve that. Validating user input and external data is important; we have tools like data validation schemas to help us with this.

Problem?

So, to recap, we have Types and schema validation schemas that basically define the same data. One is used for type-checking, while the other is used for data validation at runtime.

This is a lot of duplication, and it can lead to a situation where our schemas and our types are out of sync as your codebase scales, which could have unforeseen consequences.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

Solution

So, what are the solutions? What if we could start validation schemas and then generate a typescript? Typescript schemas have several benefits, such as being more detailed and fine-grained.

With schemas, we can check data that fits a certain pattern, such as email, phone, etc., among other checks, which is difficult to achieve with different types. So, the only thing we need to do is generate static types.

We have a few options for schema tools that we can use as our single source of truth for our Typescript types. In this issue, I will briefly examine GraphQL and Zod/Valibot as alternatives to GraphQL.

GraphQL

GraphQL is strongly typed and can be a great source of truth for describing data for our API. It has strong data validation built in and can be extended. While we can’t use a GraphQL schema directly for types, we can use it as a basis to generate Typescript types that we can use within our application, reducing code duplication and having a single source of truth.

This can be achieved using tools such as graphql-codegen; we can generate types and add more annotations to the schema to provide better types that reflect what we want our types to look like but centrally located.

In addition, you can use the GraphQL code generation tool to generate JSON schemas for data and form validation. This would allow us to achieve a single source of truth for our application and not worry about the effects of code duplication we get by maintaining different schemas and types.

Schema Data Validation Libraries - Zod and Valibot

While GraphQL is great, not everyone uses it. Zod and Valibot allow us to define schema validation schemas for data validation in our application. We can also get static types from both, which Typescript can use for type-checking within your application.

Here is an example of me using Zod to get Typescript Types from the schema.

The beauty of the above code snippet is that we can use it to validate data at runtime in places like forms. On top of that, by parsing the data, we get automatic type narrowing. Zod will throw an error if it can’t validate the data—remember to handle that.

The same can be achieved using Valibot, which I covered in a previous issue for All Things Typescript earlier this year.

Zod and Valibot are not the only two tools that can help you achieve this, but for this issue, I wanted to convey an idea and am not confident enough to recommend tools that I have tried and used previously. Still, there are a lot of good options out there for you to consider, and I will be taking a look at each in upcoming issues.

Conclusion

In this issue, I laid down my thoughts on the concept of schema first design in Typescript. This is a concept where instead of designing Typescript types ourselves, we start with a schema such as a GraphQL schema or a data validation schemas and generic static types form them. This reduces code duplication and ensures we have a single source of truth for our types, ensuring that our code scales in the future.

Let me know what you think in the comment section below.

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can also hire me to coach your team and help them improve their Typescript skills? If this sounds interesting to you, please consider getting in touch so we can work something out.

And until next time, please keep on learning.

My name is Maina Wycliffe, and I love teaching Typescript to developers. My goal is to break down complex topics into small, understandable bits that you can apply in your day-to-day life as a developer.

My First Typescript Workshop

I am excited to announce that I am working on a series of virtual Typescript workshops. The first will be in a couple of months—either later in July or early August.

The first workshop I will be doing is about a topic I am very passionate about - Schema first-type design in Typescript (I will be doing a talk in relationship to this next week for the This is Learning virtual conference (please join).

I aim to teach how to use tools such as Zod and Valibot to design schemas from which you can infer Typescript static. This will create a single source of truth together with static types.

Let me know if you are interested in joining my first workshop by answering the survey below:

I will send out a notification with details on the workshop and instructions on how to sign up.

Subscribe now

Typescript 5.5 Beta Released

The beta version of Typescript 5.5 was released last month, and I will review the features that I found rather interesting and exciting.

Some of the exciting improvements revolve around better type inference. For instance, one that I find personally exciting is control flow type narrowing when arrays are involved.

Currently, if you filter an array to, let’s say, remove undefined values inside an array, Typescript isn’t able to infer that the type needs to be narrowed.

This changes in the next version of Typescript, which can now narrow based on the control flow inside the filter method, as shown below.

This is exciting, isn’t it? Let me know if you want me to explore this further in a future issue of All Things Typescript.

Other notable features include:

• Import types into JS Docs (JS Files)

• Type-checking in regular expressions

And there is more, which you can learn by reading the announcement blog here.

From All Things Typescript

This month, I wrapped up the series around Generics and explored Typescript’s relationship with Javascript.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

From Other Authors

An intro to TSConfig for JavaScript Developers by Jo Franchetti

Have you ever wanted to understand the tsconfig. Jo Franchetti goes over the tsconfig, the different settings available, and its capabilities in this post.

Link

Introducing JSR - the JavaScript Registry

The Deno team introduced a new Javascript Registry optimized for Typescript and ESM Modules. In a series of posts, the registry discusses what JSR is and isn’t and why you should consider using it.

Here is a list of the most interesting blog posts about the registry from the Deno team.

• Introducing JSR - the JavaScript Registry

• How we built JSR

• JSR Is Not Another Package Manager

Improving Code Quality in JavaScript Projects With Qodana by Maksim Grushchenko and Kerry Beetge

JetBrains Qodana is a powerful static code analysis platform that enables teams to analyze code quality and find issues before runtime. This article discusses how to utilize Qodan to improve code quality for JS projects.

Link

Understanding 'Use strict' in JavaScript by Muslimat Mojeed

Strict mode is a special mode in JavaScript that allows developers to opt into a set of rules and restrictions that are not enforced by default.
Strict mode in JavaScript is like having a helpful friend who keeps an eye out for mistakes while you're coding.

Link

This TypeScript Trick Will Blow Your Mind by Daniel Craciun

Daniel Craciun takes us through extracting types from arrays by creating a custom utility type.

Link

Node.js Debugging in Chrome DevTools by Frontend Masters

Learn how you can utilize Chrome DevTools to debut NodeJS and Javascript applications.

Link

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If this interests you, please contact me to discuss it.

And until next time, please keep on learning.

This is unlike nominal typing, where type compatibility and equivalence are based on the type declaration. For instance, in the eyes of Typescript, the two types below are the same:

You can learn more about structural typing here.

I covered this a while ago, and I wanted to explore sub-types in Typescript in this issue. Unlike the above example, where all properties are the same across the two types, one Type has more members/properties than the other, i.e., is a sub-type of the other. Due to structural typing, the two Types have a relationship, which we will explore in this issue.

Subscribe now

We are going to start with looking at an examples:

Take the following string literal type.

type One = "One";

The one One literal type is a subtype of string and can be used in any place where the input of type one (keep in mind about structural typing) or a string is required, as shown below:

However, if we used a string instead of a variable of type One, where One is required, then it would throw an error:

This means that the type capability between the One type and string is one way; only One can be assigned to the string and not vice versa.

It is important to understand that the relationship between a Type and its subtype is hierarchical, where a subtype is always narrower than the Type.

Understanding this is important, as it allows you to form a better mental model of how the Typescript Type system works, especially type compatibility and structural typing in Typescript.

Another important reason to understand this is that it allows you to make your type more precise and narrower. Narrower types lead to increased type safety. For instance, a string literal type is always more precise than a string, and just because a function requires a string as an input, it doesn’t mean your variable needs to be a string; instead, you can prefer more narrow string literal types.

A narrower version of a string is always better than a string, as a string could be anything from a single character to a whole book.

Conclusion

In this issue of All Things Typescript, we looked at subtypes in Typescript. Type compatibility in Typescript is based on structural sub-typing, where related types are compared solely by their members (the content of a type).

In this issue, we looked at subtypes in Typescript, how they relate to their parents’ type, and how assigning subtypes to parent types is possible, while vice versa isn’t.

That's it for this issue. Thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can hire me to coach your team and help them improve their Typescript skills? If this interests you, please contact me to work something out.

And until next time, please keep on learning.

For a while now, I have been to write an issue that explores the relationship between Typescript and Javascript. While Javascript can exist without Typescript, Typescript can’t (as of the time of writing this).

As web developers, understanding Javascript is vital to developing better mental models for working with Typescript and building kick-ass applications.

The key difference between Typescript and Javascript is the existence of static types. Typescript has placed itself as Javascript but with static types. Even visiting their website, it’s right there with bold and large text.

Typescript has evolved to strive for feature parity with Javascript, but this wasn’t always the case (ahem, decorators and enums anyone).

By providing only the typing system, means adding Typescript to your project should have zero (almost, if you use enums) runtime impact. This is because, when Typescript is compiled, all the types are stripped away (after the useful tasks of type-checking) and you are left with plain old Javascript.

Understanding Typescript is just one side of the equation, where we get to learn how our code behaves up to the compilation/transpilation process. And this is where understanding Javascript is also important.

This means it’s important for us to know the behavior to expect from our application, during the runtime. This means understanding Javascript and its peculiarity. For those of us who have been around for a while, we may have come across the famous banana meme:

("b" + "a" + + "a" + "a").toLowerCase()

The expression above results with the string banana, as shown below (you can try it in your browser right now):

The trick is that when you try to sum a string, with a number, it results in the NaN value, which is a global value that represents not a number in Javascript, hence where the NaN comes from in our expression, to complete baNaNa. Even the following expression will result in banana as the value of the string.

("b" + "a" + + "not a banana" + "a").toLowerCase()

As shown below:

The above is fun and games, but goes to show you about things you can get away with in Javascript. This can be problematic, as you don’t want to make the mistake of summing strings and numbers when you meant numbers. And these are some of the problems that Typescript looks to address.

Subscribe now

I know you may be wondering where I am heading with this, but let’s explore the typing system:

The Typing System

In languages, programming languages, there are multiple ways in which we can categorize a language typing system, which allows us to make sense of the Typing system, giving us a glimpse into the behavior of a language when both writing code or our code is running.

Understanding the typing system of the language we are using can help us add some important guardrails to prevent bugs we can foresee.

There are two broad ways of looking at a language Type system:

Static Typing Vs Dynamic Typing

In this kind of type system classification, the variable types are either static, meaning that the type of a variable is known from when the beginning, at the point it’s defined (whether explicitly, or implicitly - think of type inference here). While in a Dynamic Typing System, the variables are assigned their types at runtime, the concept.

In static typing, the language requires types to be known upfront and during the build/compile step, it will type check your code to ensure type safety while dynamic typed languages do not.

Strongly Typed vs Weakly Typed

On top of being either static or dynamic, the type system of a language can either be strong or weak. A strong typing system doesn’t allow for the type of a variable to be changed when it’s assigned, either statically or dynamically, while a weak typing system, will allow the variables’ type to change, and can take different types as the variables get data assigned to it.

With weakly typed languages, variable type changes implicitly during their life-cycle while in strongly typed, this doesn’t happen.

Where do Javascript and Typescript fall in this category?

As we have said previously, Javascript and Typescript are tied at the hip, while Typescript provides a static typing system to Javascript, just because Typescript doesn’t exist at runtime, it inherently borrows some of the characteristics of the Javascript typing system - the runtime behavior. Web developers working with Typescript need to understand this.

But before I can go on and say, that Typescript is good, and javascript bad (oh, I know, no one likes hyperbole), let’s first look at them as independent languages, which is kind of hard when one compiles into the other one.

Typescript is statically typed - your variable types, even when using any have to be assigned when you define the variable - this can be done either explicitly or implicitly, relying on the inference system, but the end goal is known upfront.

You are also not allowed to change the type of variable once annotated. A few things to keep in mind here is the any type, which can be assigned to any variable and vice versa - I would encourage you to disable implicit any in tsconfig.json and in such cases, provide annotations for variables where Typescript can’t infer types explicitly, or manually.

On the other hand, Javascript is dynamically typed and weakly typed, meaning a variable’s Type is determined at runtime based on the value it’s assigned and that type can change during the lifetime of a variable.

Remember when I said, Typescript borrows some of the characteristics of the Javascript type system? The reason I said this is because, When we compile Typescript to Javascript, we lose everything and our runtime Type system is that of Javascript rather than Typescript's desired behavior.

It is important to know and understand this and why you cannot trust any data from external sources - outside your code. User input data and API data should be validated to ensure that you are working with data that matches your expectations.

And I would highly discourage using type assertions (another topic, for a future All Things Typescript issue), and instead rely on schema validation libraries like Zod and Valibot for this, which brings data validation to Javascript, at runtime.

Why do we need Typescript?

I know what you are wondering now, why do we need Typescript? Let's try and answer now by looking at what Typescript brings to the table.

Typescript adds a typing system for Javascript, allowing you to define the shape of your data and Typescript will type-check your code against the types. This ensures

By defining typescript, we are defining our intention or contract and then when we make a mistake, like passing the wrong type of data to a function, typescript prevents us from making that mistake.

This eliminates a whole class of bugs and is very beneficial, as most of the bugs can be caught at compile time before you even compile to Javascript. I find out that most of the bugs I make are typos which can be very devastating and Typescript helps guard against this very well.

Other benefits of Typescript, include auto-completion, which we get because we define the shape of our data and make the developer experience (DX) much better.

Conclusion

In this issue of All Things Typescript, I superficially explored the relationship between Javascript and Typescript, with the goal being to help developers improve their Typescript skills.

Both languages, are tied to the hip, Typescript is a superset of Javascript and apart from the typing system, Typescript looks to be TC39 compliant, meaning feature parity with Javascript.

That's it for this issue and thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can also hire me to coach your team and help them level up their Typescript game? If this sounds interesting to you, please consider getting in touch and we can work out something.

And until next time, please keep on learning.

You can find the last two issues below:

In this issue, I wanted to explore how we can make a generic Type optional by providing a default for the Type variable, that can be used when no Type is passed in and Typescript cannot infer the Type. Before we can look at generics, let’s draw some parallels with functions and how defaults work values for functional arguments.

Let’s take the following simple example.

function doSomething(input: string) {
    // do something
}

In the above example, the function input parameter is required. In some cases, we want to provide a fallback value, that will be used if the function is called without a value.

Subscribe now

For functions, the syntax to achieve this is the one shown below:

In the above example, we are simply telling Javascript that if the input parameter isn’t provided or undefined, use default-value as the value for the variable. This makes the input string optional, and not required.

While Typescript will type-check the function’s input parameter if provided an incorrect Type or if we simply don’t provide it, it also means that we need to provide the input every time we call the function.

By providing a default value, we made the parameter optional, but this also means we have also expanded the types from being just string to string and undefined and to consume it, we might need to narrow the type. You can learn more about type narrowing here.

However, by providing a default value, it means we don’t need to provide it, so we don’t have to do the extra step of checking if the input is string or undefined, avoiding the extra step for narrowing types, as we already have a fallback value, when undefined.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

What does this have to do with generics?

Default Types for generics types work similarly. We can achieve the same thing we did with function parameters with Generics, where we can provide a fallback type for the type variable if not provided and cannot be inferred.

A type variable is a special kind of variable that works on types rather than values.

Let’s look at an example. Let’s create a simple utility type. Utility types utilize generics to help you do type transformation. Typescript has some in-built utility types that you can learn more about here.

Our utility type will take two types (that are key-value objects) and merge their properties into a single Type, with the properties from both Types.

Here is an example of what our implementation looks like:

To use our utility type, we just need to provide two object types and we get a single object with properties from both types that were passed in, as shown below:

You can find the above code here.

Our example above doesn’t do much, but let’s say that in the future the requirements of our project change and we want to expand it so that we can merge two or three types.

The problem is that this would work with merging 3 Types, but to work with merging two Types, we would need to provide an empty object Type, as shown below:

Wouldn’t be nice if we could skip that part, and just provide our two types? And this is where Generic type variable defaults come to the rescue.

Just like function parameters, we can provide a default Type for our Type variable and essence making them optional, as shown below:

And now, our MergeObjectTypes utility type can accept either two or three Types and merge their properties into a single Type.

And we can go crazy now and add more type variables to merge 4, 5, or 10 even object properties while ensuring our utility types work with 2 to 10 types, and anywhere in between.

If you are interested, see if you can modify the above example to work with 5 types.

Rules for Default Types

Just like function parameters, there are a few rules to keep in mind for generic default Types.

• The first and most obvious one is that when you provide a default value, a Type variable is deemed as optional.

  • You are required to provide the required type variables.

  • Remember, Type inference in most cases can help you, so you don’t provide the required Type variables.

  • If you don’t provide an optional Type variable, then the default type is used, unless Typescript can infer a different type based on usage.

• And just for functions, required type variables come first, followed by optional type variables.

• If you are using a generics constraint, the default type must satisfy that constraint.

  

• For classes and interfaces, when extending either a class or an interface, you can introduce a default for an existing Type parameter and you may also introduce a new Typer variable, as long as it’s optional (has a type variable).

  

Conclusion

In this issue, we looked at making generics Type variables optional by providing a default or fallback type. We drew parallels between Generics default types with functions parameters default values and how they behave almost the same, but with the key difference being one applies to variables while the other one applies to types.

To demonstrate how useful default generics types can be, we took a look at an example where we can create a custom utility type that we can use to merge properties for an object type, for either two or three types, and how we can utilize defaults to make this work seamless for either of the cases.

That's it for this issue and thank you for getting this far. If you enjoyed this article and would like to support my work, please share and like this issue and consider sharing All Things Typescript with friends and colleagues.

Share All Things Typescript

Did you know you can also hire me to coach your team and help them level up their Typescript game? If this sounds interesting to you, please consider getting in touch and we can work out something.

And until next time, please keep on learning.

My name is Maina Wycliffe, and I love teaching Typescript to developers, my goal is to break down complex topics into small understandable bits that you can apply in your day-to-day life as a developer.

Typescript News

Over the last two issues, we have looked at the release process of Typescript 5.4 which was released last month, so I won’t focus on that on this issue, you can learn more about Typescript 5.4 here.

For this issue, I want to focus on the next version of Typescript which has the potential to be huge. First, before proceeding further, I want to state we are still early and some of the details might change as we get closer to the next issue. Now, that that is out of the way, let me focus on a few interesting changes:

1. APIs marked in version 5 as deprecated are going to be removed, for more information, check out this issue.

2. Ability to add imports, when you copy-paste code from another TS file, the same imports in that file, for information, check out this issue.

3. Narrowing of generics indexed access type return type, for more information, take a look at this issue.

4. And many more such as providing syntax checking for regex, for more information, check out the road map here.

Let me know if there are features you want me to cover in a future issue of All Things Typescript.

Subscribe now

From All Things Typescript

This month, I wrote two articles that explain generics which I hope for those of you who have read them and found very useful.

From other Authors

The `never` type and error handling in TypeScript by Stefan Baumgartner

This article by Stefan Baumgartner goes on to explain more about the never type, common misunderstandings about the never type, and how to correctly handle the never type for handling errors.

For more information, you can go through the article here.

This Pattern Will Wreck Your React App's TS Performance by Matt Pocock

In this article by Matt Pocock, he looks at a case where using one way of defining Typescript type can slow down your IDE performance compared to another way, especially in a large code base.

For more information, you can go through the article here.

Making Your Code Type-Safe with Zod by Leonardo Maldonado

In the past, I have made it clear I am a huge fan of tools like Zod which look to combine schema validation for forms, and runtime data validation, while also getting back to static types for you to use in Typescript. This article takes you through the process of setting up Zod and using it to make your code type-safe with Zod.

For more information, you can go through the article here.

`any` Considered Harmful, Except For These Cases by Matt Pocock

If there is anything I have spent a large amount of time doing in this newsletter, is discouraging you not to use any. In software engineering, it’s quite rare we have a definite answer the correct answer is always, it depends and this article by Matt Pocock is a great example of situations where it’s acceptable to use any.

For more information, you can go through the article here.

Intersection Types In TypeScript by Alex Khomenko

This article by Alex Khomenko takes you through an introduction and a detailed description of what the intersection types are and how you can add them to your toolbox and be comfortable using them in your day-to-day activities.

For more information, you can go through the article here.

TypeScript Intermediates - Type Generics by Corbin Crutchley

This article by Corbin Crutchley is about generics and some real-world uses for generics. He goes into detail explaining a use case, and looks at alternative solutions, before explaining why generics are a good fit and why you might consider using generics for that use case.

For more information, you can go through the article here.

That’s it for now and I will see you again at the end of April, where I will share some interesting reads that I will come across in my learning journey in April. Until then, I will continue teaching Typescript, and next week, we will take a look at Typescript Generics and default values, to wrap up my generics series.

If you found this issue useful, consider subscribing, if you haven’t and if you have (Thank you ❤️) please consider sharing All Things Typescript with your friends and colleagues.

Share All Things Typescript

Until next, keep on learning.

But to quickly recap the last issue, Generics allows us to write our code in a way the data types we are dealing with will be specified later on. In Typescript, we do this using the type variable specified inside Angle <> brackets, which we can then use within our application.

A type variable is a special kind of variable that works on types rather than values.

Here is an example of a sortArray function, that can sort any array, accepting a SortType type variable, for the function input and output.

In the above functions sort generic functions, we need to specify the type of array we are sorting by providing the SortType type variable, just before we provide the arguments for functions, as shown below.

And this can be done for classes and when defining other types using either interface or type, to learn more, check out the previous issue here.

Subscribe now

What are generic constraints?

Before we can try and define generic constraining, let’s define the word constraint, on its own. Stay with me here, I know this is a Typescript newsletter, not an English newsletter and I am probably the worst person to teach English, considering it’s probably my third language. I digress anyway.

According to the Cambridge Dictionary one of many definitions (I cherry-picked 🤷🏾), a constraint is something that controls what you do by keeping you within particular limits. The key part I want you to remember for this issue is keeping you within particular limits.

Back to Typescript and Generics, if we looked at the previous example we had, our sortArray function is meant to sort arrays, not other data types, which would probably require a different algorithm for arrays.

However, our function will accept array types as well as non-array types, and this is not the desired behavior. This isn’t type-safe, as the function will probably throw a runtime error if we attempt to sort a string data type when we wrote it to sort arrays.

Typescript was meant to eliminate these kinds of errors, but we just made it even simpler to make them, and no way to know ahead of time.

And this is where generics constraints come in. They enable us to limit (restrict or constrain) the types that can be provided for our type variables. This way, our function will accept arrays, but it will not accept non-array types. We do this by using the extends keyword and providing the types we want to contain our type variable to.

For instance, in our sortArray function, we can restrict our type variable to be only an array of string, number, or boolean, as shown below.

And now, when we try to pass in a string, as we previously did, Typescript catches the type error for us, as shown below:

Typescript now catches and warns us that we can not pass a string type as the Type variable as it doesn’t satisfy the type constraint we provided. This works with Type inference too, as discussed in the previous issue.

As you can see generic constraints allow us to achieve type safety by restricting the Types for our application. By using Typescript generics constraints, we can now write our generics code knowing that we are dealing with a known pool of types rather than all types available. In our case, we are only dealing with arrays and not non-array types.

In the previous example. we looked at constraining it to be an array, but we can constrain it to any type, as shown below:

In the first case, we are constraining to only accept strings (and their subtypes), and in the second case, we want it to be a key-value object and in the last case, we are providing our type, to just demo the different ways you can constraint a Generic.

☕️ Consider buying me a cup of coffee

Type variable constrained by another Type Variable

So far, we have dealt with simple but useful cases. I don’t want to go into some of the most advanced use cases of generics yet, because this is still a gentle introduction to generics but let’s look at another common scenario.

For instance, let’s say we want to create a function that returns a property from a key-value object, given its key, as shown below:

As you can see, we are using a Generic constraint to ensure that the first argument is always a key-value object, but we have a slight problem. We would like the second function argument - key - to be only a key that exists inside the object we pass in. At the moment, we can pass anything and this could lead to undesired characteristics from our application.

We can fix this issue by adding a second type variable that we can call Key and whose type will be constrained to the keys of the object, for this we can use the keyof operator to get the keys of the first type variable, as shown below.

And now, if you try to provide keys that aren’t present in the object in the first argument, Typescript will warn you.

As you can see, we get a warning when we provide a key that doesn’t exist and Typescript provides suggestions for keys you can use.

Bonus

There is one final thing we can do to make the function more complete and type-safe. As you can see, our function return type is unknown, which doesn’t tell us much and we would need to narrow it before using it. But we can use our type variables - the object and the key passed in, to look up the type of that property in the object.

So, we are combining the type variables provided for the getProperty function, where we are annotating the return type of the function to be the type of the property for the key provided.

In Typescript, this is known as indexed access types. Indexed access types allow us to look up specific properties of other types. You can learn more about this in a previous issue here.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

Conclusion

In today’s issue, we discussed generic constraints and why they are important in Typescript for increased type safety and improved developer experience. Generic constraints enable us to provide guard rails to the generics types so that we can be certain that the type of data that can be passed in is what is expected leading to enhanced type safety.

This hasn’t been an easy issue to write, breaking down the concepts into something easy to understand and I hope you found it very illuminating.

So, what’s next? In the next couple of issues, we will look at default types for generics types and mapped types in Typescript, but not next week, because we have our monthly newsletter.

As always, I am looking for suggestions for future issues, such as any library you would like me to cover in the future. If you have any, feel free to add a comment below.

You can also share and like this issue to help reach more people. We are getting closer to 2000 Subscribers and I will appreciate any help you can give.

Share

That’s it from me and until next week, keep on learning.

Subscribe now

What are generics?

Let’s see a useful case on why generics can be very important and even crucial. Let’s say we want to build a function to sort strings. It would look something like this.

function sortString(str: string[]): string[] {
    // sort algorithm
}

But after a while, the requirements of our project change, and we need to be able to sort numbers as well. The algorithm to sort the strings and numbers is the same but to have it strongly typed we would need to create a second function for that as well.

function sortNumber(num: number[]): number[] {
    // sort algorithm
}

In the future, the requirements of our project could change and we could end up sorting different types of variables. As you can see, we could end up duplicating the original function, more and more, as we need to be able to sort different types of arrays.

Can we use the any Type to solve this problem

Yes, we could. But this comes with one huge disadvantage, compared to having multiple functions, we lose type-safety and type precision, and we certainly don’t want this.

You can learn more about why you should avoid using the any type in one of my previous issues here.

function sort(num: any[]): any[] {
//                  ^ DON'T DO THIS
    // sort algorithm
}

☕️ Consider buying me a cup of coffee

Is there a better solution?

Before I can answer that, let’s recap. So, we want a solution that allows us to write a single sort function, without compromising type-safety and losing type precision. Back to the question, yes, there is a better solution.

What if, instead of writing a sort function with static types for arguments and return values as we did previously, we could write a function whose types can be specified when the function is being called?

So, in our case, we would allow the caller of our sort function to specify the type of function argument (the array to be sorted) and output (sorted array).

This is exactly what generics allow us to achieve in programming, and Wikipedia has a very good definition of it.

To break the above down in relationship to our sort function requirement, we want to write our sort function algorithm, without tying that algorithm to a specific type - string, number, boolean, etc. but also allow the caller to let us know the type that we can use for type-checking.

So, how do they work?

In Typescript, we use generics by providing the type variable inside angle brackets (<Type>). A type variable is a special kind of variable that works on types rather than values. You have free reign in naming the type variables, just like the naming of other variables.

For instance, in functions, we provide the type variable, in angle brackets (<Type>), in between the function name and brackets used to specify the arguments. We will see about generic classes, types, and interfaces later on. The type specified here can then be used within the function, or for arguments and return types, as shown below.

function sort<SortType>(genericInput: SortType[]): SortType[] {
~~~~~~~~~~~~~~   ^ Type Variable
    return genericInput.sort();
}

In the above function, we are specifying the type variable, which is the SortType type, and then for the function argument, we use SortType as the type of the first function argument and output. And this is how we use the above function:

const x = sort<string>(["1", "2", "3"]);

We are providing the string type, as the type variable and now Typescript can use the information to type-check the function arguments and outputs.

This works for a variety of types:

const nums = sort<number>([1, 2, 4, 5])
//            ^? function sort(input: number[]): number[]

const str = sort<string>(["str", "str2"])
//            ^? function sort(input: string[]): string

// we can even mix up things now
const both = sort<string | number>([1, 2, "str"])
//            ^? function sort(input: (string | number)[]): (string | number)[]     

If we try a different type other than the one provided in our generic type variable, Typescript is going to throw an error, as shown below:

And just like functions arguments, you can have multiple type variables:

function manyGenerics<A, B, C, D>(a: A, b: B, c: C, d: D): [A, B, C, D] {
    return [a,b,c,d]
}

Do I have to provide the type variable every time?

The answer is no, and this is because Typescript can use Type inference so you don’t have to provide the functions generic type with every call.

Typescript will use the type inferred for our generic input, as the type for our variable type, which can save you from having to always specify the type variable.

This is so good that many developers use generics daily without realizing it. For instance, the Array.sort() functions and other Array methods are generic functions.

For instance, the following Array.map method:

[1, 5, 3, 11, 6 ].map(x => x.toString());

It can also be written like this, with the type variable provided.

[1, 5, 3, 11, 6].map<string>(x => x.toString());

Where else can we use generics?

So far, we have seen generics in function space. But we can use generic in a variety of places, not just functions. Let’s see some of this:

Classes and Methods

Just like functions, when defining a class, we can request a type variable(s) for the class, which we can then use within the class.

class SomeClass<Type>{
// ~~~~~~~~~~~~~ ^ Type Variable

    property: Type;
    //         ^ We can use the Generic type for types of properties

    doSomething(input: Type): Type {
    //                  ^ and for methods input
    }
}

And on top of that, we can provide type variables for the methods themselves, if need be:

class SomeClass{
    doSomething<Type>(input: Type): Type {
        //       ^? Type Variable
    }
}

Types and Interfaces Definition for Key-Value Objects

When defining types for key-value objects using either interface or type, you can use generics to provide types for some of the properties.

type Person<Type> = {
//            ^ Type Variable
    name: string;
    id: string;
    properties: Type;
}

We can do the same with interfaces:

interface Person<Type> {
//                ^ Type Variable
    name: string;
    id: string;
    properties: Type;
}

What’s next?

So far, we have had a very brief introduction to Typescript generics, where we looked at creating Generics in Typescript and how we can use them. Generics are powerful and are very useful and in our next issue, next week, we are going to look at constraining our generic type.

See you next week and subscribe to not miss the next issue.

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

☕️ Consider buying me a cup of coffee

Conclusion

In this issue, we looked at Typescript generics. We looked at a simple example of a sorting function, that enabled us to see in which situations generics can be very useful and how generics can help us write less code without compromising type safety.

In the next issue, we will continue looking at generics and some advanced techniques that we can do with generics to even lead to more Type safety.

So, until next, keep on learning.

Subscribe now

Announcements

Typescript 5.4 RC Released

We are getting closer to the release of Typescript 5.4 and in February, the release candidate was announced.

Here is a summary of the features to expect:

• Assignment Narrowing is Preserved in Closures

• New NoInfer Utility Type

• Type Declarations for Object.groupBy and Map.groupBy

• Support for require() calls in --moduleResolution bundler and --module preserve

• Checked Import Attributes and Assertions

• Quick Fix for Adding Missing Parameters

Let me know if there are any features you want me to take a look at in the next few issues of All Things Typescript.

Please check out the release blog post here for more information about the above features.

All Things Typescript Feb 2024 Issues

In February, I consistently released articles every week, except one. In case you missed any, here is a list of the issues that I released in February.

From other authors

Articles

When 'as never' Is The Only Thing That Works by Matt Pocock

TLDR: as never is very occasionally needed in TypeScript. Let's look at an example where it's necessary.

Link

Using Generics In TypeScript: A Practical Guide by Alex Khomenko

TLDR: Among these features, generics stand out as one of the most powerful tools for creating flexible, reusable components without sacrificing type safety. In this blog post, we'll dive into the world of generics in TypeScript, exploring how they can be used to write cleaner, more maintainable code that is robust and easy to understand.

Link

TypeScript Advanced Types: Working with Conditional Types by Alex Khomenko

TLDR: Conditional types in TypeScript provide logic to type definitions, allowing for type transformations based on certain conditions. They can be used for type inference, filtering types with utility types, building type-safe API handlers, and defensive programming. Best practices include keeping conditions simple, using type aliases and utility types, and testing types. Limitations include operating at compile-time only and not being suitable for all use cases.

Link

Understanding Async/Await and Promises in JavaScript and TypeScript by Geoffrey Kim

TLDR: This blog post aims to demystify the scenarios where you might or might not need to use await when dealing with Promises, through detailed explanations and illustrations.

Link

How Types Work in TypeScript – Explained with JavaScript + TypeScript Code by Sahil Mahapatra

TLDR: In this comprehensive guide, we'll explore TypeScript's basic types by comparing them with their JavaScript counterparts. I'll also clarify the differences and advantages offered by TypeScript's static typing features.

Link

ESLint no-unused-vars: _ ignore prefix by John Reilly

TLDR: One thing that I missed when switching to the ESLint option is that, with noUnusedLocals and noUnusedParameters, you can simply ignore unused variables by prefixing a variable with the _ character. That's right, sometimes I want to declare a variable that I know I'm not going to use, and I want to do that without getting shouted at by the linter.

It turns out you can get ESLint to respect the TypeScript default of ignoring variables prefixed with _; it's just not the default configuration for no-unused-vars. But with a little configuration, we can have it. This post is a quick guide to how to implement that configuration.

Link

Videos

There’s a fast new code editor in town by Fireship

8 NEW JavaScript 2024 Features by Web Dev Simplified

I didn't know snapshot testing was a thing by Joshua Morony

If you like my content and want to support my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity and determination ☕️) through Github Sponsors.

Share

That's all for now. I'll see you again at the end of February for another monthly recap.

• Why it exists

• Why not annotations

• Why not assertions

• When to use it

📢 Sponsored: Ready to Move From AI Hype to Real-World Results?

At Unstacked Labs, we specialise in building practical AI agents, like the one in this article, that automate complex workflows and solve real business problems.

Let's discuss your company needs

What is the satisfies Typescript operator

According to the Typescript docs, the new satisfies operator lets us validate that the type of an expression matches some type, without changing the resulting type of that expression.

So, what does this mean? When we add type annotations to a variable, Typescript doesn’t usually infer the Type to its narrowest possible value. So, if we say a variable’s type is a string, Typescript takes our word for it and checks the value we assign to it against the type annotation we provided, as shown below:

const str: string = "hello"

In the case above, despite us using const, and having all the information at hand to narrow the above type to the hello literal type, Typescript doesn’t do that and instead takes our annotation as the type of the variable.

This is in contrast to when we allow type inference to work for us, instead of explicitly providing Type annotations, as shown below:

As you can see from the above example, when we use explicit type annotations, we lose the narrower type that we would have gotten if we had let Typescript infer the type for us.

Why is this important, you may ask? To answer this, let me show you an example, take the following two functions:

function a(input: string) {
  // do something
}

function b(input: "hello") {
  // do something 
}

The first function accepts a string and the second accepts a literal type - hello. With the first variable, we annotated the type explicitly, this can be passed to the first function without any issues.

But in the second function, despite the first variable value being hello, Typescript will make you jump through to accept the variable, simply because it expects a narrower type than the type of string we provided.

In the second function, you would need to narrow the variable for it to work, as shown below:

if(str === "hello")  b(str);

In our case above, we are using control flow to narrow the type of str variable to hello, from a broader type of string. You can learn more about type narrowing in this previous issue.

How does the satisfies operator help?

If you are wondering what this has to do with the satisfies operator, I am getting to the point in a moment.

What if you wanted to ensure that str is a string, without losing the narrowness of the inferred type? If you remember at the beginning, we said that the satisfies operator allows you to validate (think type-check) a variable type without changing the resulting type of that expression. The resulting type being the Type inferred by Typescript in the absence of explicit type annotation.

So, if we went back to our example, instead of using type annotation for our variable, and instead we used the satisfies operator, as shown below:

const str = "hello" satisfies string;

Our variable wouldn’t carry the type of string as it did previously when we used type annotations, but the resulting inferred type is retained.

And this means, we can now pass the variable to the second function without needing to narrow the type.

const str = "hello" satisfies string;
//    ^? type = "hello"

// this works now
b(str);

“Real-world” Example

Okay, I know what you are thinking, this isn’t a practical example. And that’s true, but I needed a straightforward example, that hopefully was easy to follow and understand, which I hope worked, and if it didn’t let me know in the comment section below.

Let’s see a more realistic example. Let’s say we want an object, with property names being string and values being either string, number, or boolean, as shown below:

const user = {
    firstName: "John",
    lastName: "Doe",
    age: 5,
    isMember: true
};

With the above object, we might want to have Typescript type-check the content of the object. In such a situation we have two options:

• providing explicit type annotations

• or the satisfies operator.

If we use type annotations and try accessing one of the properties, Typescript doesn’t know the properties that are inside the object or their types, this is despite us explicitly adding them and adding them upfront.

const user: Record<string, string | number | boolean> = {
    firstName: "John",
    lastName: "Doe",
    age: 5,
    isMember: true
};

In this case, Typescript goes with the type from our Type annotation for the property values.

This isn’t great, for one, we can include properties that don’t exist inside our user object or typos and which may introduce bugs within our codebase. However, if we went with the satisfies operator, then things work out quite differently and for the better.

const user = {
    firstName: "John",
    lastName: "Doe",
    age: 5,
} satisfies Record<string, string | number | boolean>

If we try and access the property firstName, we get both auto-completion 👌🏾 and it has the correct type, as shown below:

We also can’t access properties we didn’t explicitly add to the user object.

And we also get the excess property checking we got when we provided explicit type annotations.

This has a few benefits:

• Improved type safety as demonstrated in the last example. This is twofold:

  • validating the object properties and values are of certain types, and

  • avoiding changing the objects’ inferred type, which means the property value types are narrow instead of wide.

• Reduced the amount of code we write - we don’t need to engage in type narrowing to use our properties above, they already have a narrow type.

Use Cases

Now that we have seen how we can some of the use cases of the satisfies operator.

Constraining the type of variable

We can use the satisfies operator to constrain or limit the types that can be used for a variable, without interfering with the type inference. A good example of this is our example above, where we limited our variable str to string, but let it be inferred as a narrower type by typescript, using the available information.

const str = "hello" satisfies string;

Constraining the Property Names of an Object and Catching Excess Properties

We can use the satisfies operator to make sure our object only has the keys and nothing extra.

type Circle = {
  shape: "circle";
  radius: number;
}

const circle = {
  shape: "circle",
  radius: 4,
  anotherKey: 4
  // this will throw an error as shown bolow
} satisfies Circle;

Constraining the values of Properties, the opposite of the above

The following will throw an error because the shape property is missing.

const circle = {
  radius: 4,
} satisfies Record<any, number>;

Ensuring an Interface is Implemented

interface Person {
  delete: () => void;
  get: () => Record<string, unknown>
}

const thisPersion = {
  delete:  () => {};
  get: () => ({})
} satisfies Person;

For more about the satisfies operator, check out the following issue, where the discussion for adding the satisfies operator to Typescript happened.

Conclusion

In this issue, we took a look at the satisfies Typescript operator, and how it can be used to validate a type, without changing the inferred type of the expression. This is different from how both type assertions and annotations work because Typescript takes that as the type of the object, which is sometimes not desired.

When using the satisfies operator, Typescript only type-checks our variable against the provided type while inferring the type using the information available (Learn more about Type Widening here).

The inferred type is usually narrower, meaning it can be used without the need for narrowing, which may not be the case for using assertions and annotations, while also type-checking it against a specific type, which ensures type safety isn’t compromised.

If you loved today’s content and would be interested in supporting my work, please consider supporting me (you can buy me a double latte, the juice that powers my creativity ☕️) through Github Sponsors.

Share

That’s it from me and until next week, keep on learning.

Why a validation schema, you may ask? This is because data coming from untrusted sources should always be validated, for instance, form data, ensuring that you are working with data that is accurate, complete, and clean. Another example of this is data from APIs among other sources.

Back to my hypothesis, this means you will need to write about two different pieces of code that basically say the same thing - describe the shape of the data for the form. And as you know about Typescript types, they don’t exist at runtime, so you will definitely need a validation schema for runtime purposes.

What if, we could write one and automatically have the other inferred? And this is where tools like Zod and Valibot, among others, come in. With Valibot, we can define a Valibot schema for our data and then use Valibot to infer a static type for Typescript.

Let's look at a simple example. For instance, let’s say, we are dealing with a simple sign-in form, with 2 fields - an email and a password.

This is what a Valibot schema looks like:

With the above schema, we can infer static types for Typescript, which we can use within our application in places like function params Types, as shown below:

And here are the results, a Typescript static type:

As you can see from the above example, we just wrote a simple Valibot schema for our sign-in form and we got back static types for Typescript. Isn’t that cool?

Subscribe now

So, what’s Valibot

Now that very long intro is out of the way, let's look at what Valibot is.

According to Valibot (And yes, the docs are written in the first person):

Hello, I am Valibot and I would like to help you validate data easily using a schema. No matter if it is incoming data on a server, a form or even configuration files. I have no dependencies and can run in any JavaScript environment. - Valibot.

In simple terms, it’s a runtime schema validation tool, which you can use to validate data coming from unknown/untrusted sources, i.e., forms, files, and APIs. Once data is parsed by Valibot, Typescript can infer the static type automatically.

For instance, continuing by our previous example above, we can parse data, as shown below:

Please note, in the case of the above example, since data is an empty object, it would fail validation and throw an error, so we would need to catch the error and process it.

And just like magic (not magic, but the powers of Valibot), our result variable now has a correctly inferred type, as shown below:

And the best part is, the validation will work during runtime, so, no matter the data source, we can consume it within our application, knowing that it’s what we want it to be.

Benefits of Using Valibot

The first and most obvious for those who have read this issue so far (Thank you by the way ❤️), is static type inference from our Valibot schemas. We don’t need to write duplicate pieces of code to describe the same data - a Typescript type and a validation schema.

Once we write a Valibot schema, we can get Typescript static types that we can use within our application, and upon parsing the data, Typescript can infer the correct Type.

This is huge for developer experience, as it reduces the amount of duplication within our application and now we only have to update our schema and our Types will be up to date.

This is by far for me, the most attractive proposition for Valibot and other tools like it, that do the same.

On top of the above, you can validate everything from complex objects to simple strings and numbers, etc, as shown below:

Impressed yet? For more information, check out the official docs here.

Lastly, it’s very lightweight, measuring about 1.4KBs to validate a simple login form, which means it’s not expensive to download and consume in browser environments. This is made possible by Valibot modular design, which enables tree-shaking and removal of any unused code during the bundling process.

Examples of Using Valibot

Now, that we have looked at what Valibot is and why you would want to use it, let’s take a look at a few examples:

Parsing Data

Valibot provides several ways to parse data, the default way throws an error if validation fails, which you need to catch and do something about it.

On top of the above option, Valibot provides a safeParse method, that instead of throwing an error, will return an object containing output (the validated data) and issues.

You can learn more about Valibot issues here.

Finally, Valibot also provides a Type Guard option, allowing you to check if data parses a validation check, which returns true or false and can be used for Type Narrowing as shown below:

Primitives

Here are the Javascript Primitives: string, number, bigint, boolean, undefined, symbol and null.

Valibot supports all the above primitives:

Optionals: Undefined and Null

Sometimes, undefined, null or both are valid values, when a value isn’t required. So, Valibot provides you with functions to make this possible.

Error Messages

And finally, you can customize error messages, so that when validation fails, you can provide nice messages for your users, so that it’s easy to know and understand what went wrong.

Conclusion

In this All Things Typescript issue, we looked at Valibot - a runtime schema validation library that can be used to validate data at runtime and ensure the integrity of data flowing within our application.

On top of that, we looked at how we can utilize it in Typescript so that we can avoid code duplication, and get static types from the Valibot schemas we create. This has the overall effect of improving the developer experience we enjoy without sacrificing much, apart from maybe learning some newer syntax - the Valibot Way of doing things.

If you would like to learn more about Valibot, check out the official documentation here.

Share

I hope you learned something from today’s issues and I am open to suggestions for the next topics to cover for All Things Typescript. If you have any suggestions, feel free to drop them in the comment section below.

Otherwise, until next time, keep on learning.

Share All Things Typescript

I am very excited to let you know that starting in January 2024, I will be sending out a monthly curated list of top articles and resources related to Typescript and other relevant technologies. This list will be sent out on the first Monday following the end of each month.

Although I share these articles on my social media, I wanted to create a central place where all of my subscribers could find all the useful resources related to Typescript I come across regularly. This is a return to the roots of the contents of this Newsletter, which was mainly focused on curating Typescript resources.

For those who are still interested in my regular content, don't worry, as it will continue to be sent out every week.

I appreciate your support.

Announcement

TypeScript 5.4 Beta Announced

In late January, the beta version of Typescript 5.4 was released. Some of its features include:

• Assignment Narrowing is Preserved in Closures

• New NoInfer Utility Type

• Type Declarations for Object.groupBy and Map.groupBy

• Support for require() calls in --moduleResolution bundler and --module preserve

• Checked Import Attributes and Assertions

• Quick Fix for Adding Missing Parameters

For more information, check out the official announcement here.

My Articles

Articles

Daniel Rosenwasser on TypeScript and What’s Ahead in 2024 by Loraine Lawson

In this Q&A with The New Stack, Rosenwasser shared TypeScript’s most significant developments in 2023 and provided a preview of what developers can expect to see in the coming year.

Link

Solving TypeScript Errors by Matt Pocock

In this tutorial, you'll find challenges centered around reading error messages and practical solutions to solving the issues they describe.

Link

The Bun Shell by Jarred Sumner

The Bun Shell is a new experimental embedded language and interpreter in Bun that allows you to run cross-platform shell scripts in JavaScript & TypeScript.

Link.

Using Zod's schema to render a reusable and dynamic Angular table component by Tim Deschryver

In this blog post, we'll see how to use Zod to dynamically build a (minimal) table as a reusable and typesafe Angular component. For this, the following Person schema will be used within the next snippets.

Link

Everything You’ve Always Wanted to Know About TypeScript’s Integration in WebStorm by Jan-Niklas Wortmann

Ever tense up when a new TypeScript version drops? You cross your fingers and hope it plays nice with your IDE. You’re not alone. Relax into this fireside chat with WebStorm lead developer and Team Lead, Andrey Starovoyt, as we pull back the curtain on TypeScript’s integration in WebStorm.

Link

Modern JavaScript library starter by Tamás Sallai

How to publish a package with TypeScript, testing, GitHub Actions, and auto-publish to NPM

Link

TDD: Writing Testable Code by JavaScript Scene by Eric Elliott

Writing testable code is a vital skill in software engineering. Let’s explore practical advice, strategies, and tactics for writing more testable code, unlocking the benefits of modularity, reusability, and high quality software in your projects.

Link

Writing type safe API clients in TypeScript by Nazeel

Writing API integrations can be a daunting task. But it does not need to be. How many times have you had to deal with these problems?

Link

Leveraging TypeScript for domain-driven design by Matteo Di Pirro

Domain-driven design (DDD) is a software development approach that aims to simplify the creation of applications that involve complex business logic. In this article, we’ll explore how to leverage TypeScript for DDD. TypeScript’s sophisticated type system enables fine-grained domain modeling and is highly adaptable, lending itself to complex app development.

Link

The Discriminated Union: Writing Easy-to-Use Types in TypeScript by Peter Van Drunen

TypeScript’s flexibility is one of the reasons I love using it. Unfortunately, that flexibility also provides opportunities to write confusing code. The main area where I see developers struggling is defining types that make writing code painful or verbose. Often, this comes in the form of using optional fields to extend types so they represent too many ideas within the same type.

Link

That's all for now. I'll see you again at the end of February for another monthly recap.

Subscribe now

What is Bun?

NodeJS is the dominant Javascript server runtime environment for Javascript and Typescript (sort of) projects. But over the years, we have seen several attempts to build alternative runtime environments such as Deno and Bun, today’s subject, among others.

These newer alternatives focus on providing much better runtime performance, much better support for Web APIs on the server, and generally better security among other features, we will look at in later sections. The NodeJS team also continues to make improvements to NodeJS and we have seen tremendous improvements in here as well.

Compared to Deno, what I think makes Bun special, is that it’s a drop-in replacement for node (you don’t have to change much if anything at all). Unlike Deno which required you to make significant changes to your application at launch to adopt it, Bun doesn’t require you to make any changes to your codebase.

With Bun, you can go into any node-js-based project, like let’s a Next JS or React Application, and just run bun install (yes, but install you read that correctly not npm install) and then run the bun run dev (or whatever npm script you use to launch your project) and it should run your application, just like Node JS.

From my experience, this ran flawlessly all the time I tried it.

So, why use Bun?

So, now that I have briefly introduced you to Bun and why it’s a very interesting project, let's see some of the advantages of using Bun, over Node (where most of us are probably coming from), and the others.

Speed, it’s Fast, Really Fast

NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.

Even the choice of the programming language to use Zig was done with performance in mind. The team chose Zig programming language as it allows them to have low-level control of memory management and lacks hidden control flow, making it easy to write fast software.

The same can be said about the team’s decision to go with JavascriptCore. Both NodeJS and Deno are based on Chrome V8 Engine, while Bun is based on Apple's JavaScriptCore. While not mind-blowingly faster than the V8 Engine, it’s a little bit faster. And these optimizations have paid off for Bun, as it’s faster than both Deno and NodeJS.

To demonstrate this I put my novice benchmarking skills to the test. To run the benchmarks, I used the latest versions of NodeJS, Deno, and Bun, as of the time of writing this issue.

For benchmarking, I used the following simple JS code:

for (let i = 0; i < 10000; i++) {
  console.log(`Count: ${i + 1}`);
}

And then I used hyperfine to run the benchmarks on my MacBook Pro 14 M2 Max, and here are the results:

As you can see, Bun is 2.20 faster than Deno and 2.88 faster than NodeJS. I also ran the same benchmarks on Windows 11 using WSL and Bun managed an even more impressive feat, being 3.06 times faster than node and 3.26 times faster than Deno, as shown below:

🤔 Interestingly, the Gap between NodeJS and Deno seems to be closing, let me know in the comment section below if you want me to do a deep in dive comparing the three on different workloads and different OSs.

If you want to dig into the performance comparison and a very good explanation of the internal workings (in relationship to Javascript Engines) of NodeJS, check out this amazing video by Chris Hay.

Compatibility with NodeJS and NPM

I touched on this earlier, if you are already using NodeJS and would love to switch to Bun, you can do so with minimal effort. You can visit any NodeJS-based project, run bun install and then run the server using Bun instead of NodeJS, no code changes are needed right out of the box.

For more information on NodeJS APIs implemented by Bun here.

And if all you just need is a much faster package manager, you can use Bun to replace NPM and use NodeJS for your server, no fuzz.

You can learn more about bun install here.

Built-in Tooling

One of the most frustrating or overwhelming things especially for novices about modern web development is the amount of tools that you need to learn. For starters, you will need node/deno/bun and npm, and if you decide to use Typescript, you will need a transpiler and maybe (by maybe I mean, most certainly) a bundler and the story goes on.

We, as web development veterans, sometimes forget how intimidating this can be for beginners, I guess you can call this Stockholm syndrome.

With Bun, you only need Bun. It’s a drop-in replacement for all of the above tools above. Want to install packages, bun has got you, with Bun package manager, it’s a runtime and bundler and will transpile and run typescript code, without you having to install a host of tools to achieve the same.

What about testing? Yeah, Bun still got you with an inbuilt test-runner, goodbye Jest?🤷🏾. Bun is fully compatible with jest syntax and you can use it as a drop-in replacement for jest, and you get all the benefits of Bun discussed in this article.

You can learn more about Bun testing here.

Web Standard API

One thing that serves as a divide depending on the runtime you are targeting is how some APIs are available on the browser, yet are missing on the server (NodeJS). This means that even for tasks you can perform in both the server and the browser, it’s possible to have two different APIs for achieving the same on both, despite the fact you using the same programming language.

A good example of this, until recently, was fetch, a common task like fetching data over HTTP, which you can perform on both the browser and the server. It was natively supported in the browser environment but not supported natively by NodeJS. This can be frustrating because despite the fact you are writing Javascript, the tooling changes based on your target environment.

Bun aims to address this by providing and implementing a list of standard web APIs that are similar to the ones available in the browser environment. Of course not all APIs available in the browser are required in the server environment, think of the DOM and History APIs as good examples of this.

But common tasks in both environments such as making HTTP calls don’t need to have unique Web APIs for each environment. Bun implements the Web Standard APIs for some of this, instead of re-inventing the wheel, which makes our Job (especially full-stack developers) a tad bit easier.

You can find a comprehensive list of Web Standard APIs implemented by Bun here.

Supports Typescript and JSX/TSX out of the Box

With Bun, you don’t need to transpile your Typescript code to Javascript to execute it (or result in using something ts-node). You can execute your Typescript directly using Bun, and it’s going to do all the heavy lifting for you - the process of transpilation, and executing the resulting JS code, without you having to think about it.

One very important caveat, that I missed before and I was corrected in the comment section below, is that Bun doesn’t perform type-checking, unlike other build tools, just does transpilation. You will still need the Typescript compiler to Typecheck your code.

On top of that, it does support JSX (TSX by extension) out of the box, compiling it internally to JS code ready for execution. In both cases, Bun will respect your configurations (tsconfigs/jsconfig) during the transpilation/conversion process.

You can learn more about Typescript support here and JSX here.

Single File Executables

Ever wanted to run compile your javascript into binary executables that you can run directly? Bun got your back here as well, you can compile Typescript and Javascript projects, including all dependencies into a single executable binary that you can distribute and run, without needing to install dependencies or even Bun itself.

On top of that, you can embed files and even databases such as SQS Lite, if you want to. Please note, that if you embed SQL Lite, it runs in memory and the changes will be lost when the binary exists. This does give you several choices when it comes to distributing your projects, which doesn’t require the OS to have all the dependencies installed to run.

Bun Resources

Let’s say you are interested in learning more about Bun and probably give it a try. Bun has a website, where you can learn more about Bun and its features (including all the benchmark data captured in this issue), and here is the link.

1. Bun Documentation

2. Installation Instructions

3. Getting started with Bun and React

4. Learn Bun, a faster Node.js alternative

Conclusion

In this issue, I have done something different from my usual content. We have gone over Bun, a Javascript server runtime environment which is a drop-in replacement for NodeJS. We took a look at some of the features that set Bun apart from NodeJS and which might tempt you to switch to Bun.

That’s it from me and until next time, keep on learning.

The any Type in Typescript

One of the most controversial types in Typescript is any, this is because it could be anything, and can be assigned to all variable types and assigned to all variable types, and as such Typescript doesn’t do any type checking when the any type is involved. Yes, that’s how powerful the any type is in Typescript.

As you can imagine, for a statically typed language that aims to provide type safety, this is a misnomer, an anti-pattern and any (pun intended☺) type nerds worth their salt in the Typescript will frown at you for using any.

So I guess the question now is, why does it even exist? In order to understand why any exists, you need to understand the Typescript type system. If you are trying to master Typescript, one of the very first mental models you need to form is that a Type represents a possible set of values. What do I mean, if the type is a number, then that represents only numbers, and boolean, just true and false.

This means that when a variable has a type, it can only be assigned values within the set, and errors if it's assigned variables outside the set. When it comes to the any type, this is an open set, meaning any possible value from string, numbers, boolean, etc. forms the set of the any type. Basically, it means all possible values in existence can be assigned to a variable of the any type.

This made sense for Typescript originally, if Typescript was going to experience widespread adoption from Javascript codebases, it needed to support a way of doing gradual migrations. Hence, you could use the any type, both implicitly and explicitly, for any parts of our codebase that we weren't ready to adopt Typescript fully yet. We still do this, even today, when migrating to Typescript from a Javascript codebase.

Subscribe now

So, why avoid any then?

If you have learned anything so far, the any type is very powerful. It has a few superpowers that can easily be abused.

First, the any type can be assigned to any variable of all other types → string, number, object, etc, it doesn’t matter. And the vice-versa is also true, any value can be assigned to a variable with any type.

This can cause unintended bugs within our system because any could be anything, the Typescript type checker won’t type check the code when any is involved. You could end up in a situation where you expected a number for customer balance calculation, and instead got something completely different, at the very least providing an unreliable experience to users of the system or could be worse.

This is something we Javascript/Typescript developers need to be keenly aware of, as the any type also has another superpower, disabling the Type checker. Typescript has no way of Type checking a variable of any type and developers mostly use the any type to disable Type checking in Typescript applications.

Unlike all other types in Typescript and by extension Javascript (yes, Javascript has types too, just not static types → I have an article in the draft that I should finish about this), any is very contagious, and if you assign a variable to the any in place of any other variable or vice versa, Typescript will not warn you, while in case you pass a string in place of a number, Typescript will not let you.

My point is to avoid using any unless it’s absolutely necessary or type checking is not really necessary, which in most cases is. As developers, we are paid big bucks to make these decisions, but just like tests, types are not only there to prevent regressions within our codebase, but also help improve the developer experience, as we can refactor and make changes within our codebase with a lot more confidence, as compared to when types don’t exist.

What should I do now?

Let’s say you buy into my argument (hooray 🥳), what should you do? There are two main types of any within your codebase, the explicit any and the implicit any. I don’t want to dive too much into the explicit any because those are any types that we as developers (or our teams) have introduced knowingly within our codebase. The solution is to provide proper types, check out the next section if you can’t, you might find better solutions than just using any. If you are struggling with this in your codebase, consider tracking Type coverage.

The second one is implicit, this could come from us not providing types and Typescript doesn’t have enough information to infer the type of a variable and hence implicit any, for instance, the following function:

functions doSomething(var) {
                    // ^ implicit any 
}

You can remedy the above issue by setting typescript to throw an error instead of implicitly inferring a variable type as any. This can be achieved by updating the tsconfig settings and setting noImplicitAny to true. You can also update the useUnknownInCatchVariable property to true while at it so that errors are inferred as any instead of any in try-catch blocks.

The second possible source of this is third-party libraries that ship without Type declarations or ship incomplete or inaccurate Type declarations. NPM packages ship as Javascript, not Typescript, they have to be usable in the whole ecosystem, including Javascript-only projects. To support Typescript, libraries can ship with Typescript declaration files, which provide Type information about a library that Typescript can use for type checking.

You need to be aware of this and can remedy this by installing types from Definitely Typed if they exist or you provide the type declaration yourself. For instance, if you using React, which doesn’t ship with type declaration, you can do the following:

npm i --save-dev @types/react

And just like that, you will Typescript and react to play nice. I will cover providing your own type declarations in a future issue, let me know if you are interested below.

Also, as I previously touched on at the beginning of this section, please consider tracking Type coverage to aid in improving type safety in your codebase and be aware of where you are trending. You can learn more here in one of my previous issues.

What if I can’t avoid any?

There are situations where you can’t avoid the any type, maybe because you don’t have enough information to define the type or it’s not important because you are not consuming the data within your application, think of a log dump application or a proxy server. In both cases, you don’t care much about the content shape, as long as save the data being sent to you properly or redirect the requests to the correct server and responses back to the client.

In this case, I would advise you to consider preferring the unknown type. The unknown type is another powerful type in Typescript, and just like any, all other types can be assigned to the unknown type. However, this is how it differs from the any type, it can only be assigned to another unknown type or any type.

This means that before using unknown, you will need to resolve the underlying type either using assertions (please avoid) or Type narrowing. This makes the unknown type is not contagious as it can’t spread within the codebase just like the any type.

If you can’t avoid the any type, I would encourage you to use a more narrower version of the any type. For instance, any[] or Record<string, any> is a lot better than just any. In both cases, we are containing the superpowers of the any type but limiting what types can be assigned to the two types, in the first case, we are saying it has to be an array, the content could be anything, and in the second case we are indicating it has to be an object, with the string keys, but the values could be of any type.

Is this the best way? Definitely not, but in my eyes and in some special circumstances it’s better than than just using any.

Conclusion

That’s it, we have reached the conclusion of this article, where we discussed about the any type, why it exists, and why you should avoid it. We learned that any exists to make it easy to turn off Typescript hence aiding in the gradual adoption of Typescript, which played a hand in helping in the adoption of Typescript. We also learned that any can be contagious and spread within our codebase, which can lead to bugs.

We also learned about the unknown type which is a good alternative to any when we can’t avoid it and how we can instead prefer a narrower version of the any Type instead of just using any when we don’t have a choice.

Share

Previous issues you might be interested in