Every week, either Wednesday or Thursday, I will do a more compact scoop on different Typescript-related topics and practices to help you understand Typescript even better.

I also send out deep dives content every Monday, where I cover more complex concepts such as how to Overload Functions in Typescript.

Please consider subscribing to this free newsletter if you haven’t, and share it with friends if you already have.

Subscribe now

Thank you.

One thing I usually love doing when looking for NPM packages to use is to try and figure out if it’s written in Typescript or not. Why? Because it can be excruciating using a third-party dependency without the benefits of type declarations for the libraries - type safety, easy to look up documentation for code, and auto-completion (IntelliSense) in your favorite editor.

I do this because most Javascript libraries written in Typescript will usually ship with their declaration files. Code editors will automatically pick this for autocompletion/IntelliSense while Typescript and Linters for type checking and linting. Once you have installed the npm package, you don’t have to do anything extra concerning the library types.

What if it’s written in plain Javascript? Libraries written in plain Javascript can still ship their types if the maintainers want, but it’s not very common to see that, so in this case, the next place to look for types is DefinetlyTyped.

Please note: it also possible to find a library written in Typescript, that doesn’t ship with it’s type declarations.

The DefinitelyTyped Project

DefintelyTyped is a community-driven project for a central place where types for popular javascript libraries can be found. The community (not necessarily the authors) contributes to the type declaration for libraries which are then made available to everyone via NPM. Everything is scoped under the @types name, and if you, for instance, were interested in express types, you would install @types/express with the name of the library being the package name. Once you have installed the above express types, Typescript will pick them up automatically to type-check your code.

Please Note: The Typescript language service is usually clever enough to determine that an npm package you are using doesn’t have any declaration files shipped. It will usually suggest that you install the types from DefinitelyTyped if available.

Unlike types that ship with libraries, DefinetlyTyped types are shipped independently of the libraries they provided types for. This means you need to be aware of this and ensure that you have type compatibility between the installed version of the library and its types from definitely typed. If you are not careful, you might end up in a situation where your code type-checks correctly, but there are bugs at runtime since the source of the types you have is not for the version of the library you have installed.

Defining your types for Libraries

Suppose you can’t find the types for a library you are using in the DefinitelyTyped project. This happens when a project doesn’t have a lot of users; hence not enough people to contribute to the type declaration for the package.

In that case, you might consider creating type declarations for the library you are consuming locally. If you find yourself in this situation, please contribute; someone else will appreciate it and help improve your work so that we can all benefit.

You can achieve this by creating your ambient declaration files within your project. These files have an extension .d.ts and are a way of informing the typescript compiler that something library exists at runtime or some library has certain types.

This is going to be the topic I am going to explore next week on Monday. Please subscribe not to miss out.

And that’s it from me, I hope you enjoyed ❤️ this issue as much as I did writing it, and I hope you have a fantastic week ahead.

Please consider doing one of the following things if you love this issue.

1. Share it ❤️ - Help me spread word of mouth and help All Things Typescript grow:

Share

2. ✉️ Subscribe to this newsletter. You will receive weekly content like this from All Things Typescript that will help you learn and master Typescript.

Subscribe now

3. Consider Sponsoring me on GitHub ❤️; you will be helping me create more free content for the benefit of everyone.

Please consider sponsoring me ❤️

Au revoir 👋🏿.

So, without further ado:

So, how does Typescript compare two functions and determine whether they are assignable to each other? Let’s take the following function Types:

type F1 = () => void;
type F2 = (input1: string) => void;

In Typescript, we can assign a variable typed as F2 above to FI, but not vice versa:

let f1: F1 = () => {
    console.log("F1")
}

// this is okay
let f2: F2 = f1;

// this will error
let f3: F1 = f2;
//   ^ Type 'F2' is not assignable to type 'F1'

Why? In this case, typescript mirrors this behavior from Javascript, where it’s quite common to ignore extra parameters of functions when we are not using them. Remember, Typescript compiles to Javascript and adds a typing system (mostly) on top of the features that Javascript provides; this means mirroring some of the behavior from Javascript whenever it doesn’t compromise Type Safety.

The reason for this assignment to be allowed is that ignoring extra function parameters is actually quite common in JavaScript. For example, Array#forEach provides three parameters to the callback function: the array element, its index, and the containing array. Nevertheless, it’s very useful to provide a callback that only uses the first parameter

Link to docs.

Typescript will not allow you to provide function parameter types that do not match the parameter types in each position. If we tried to do the opposite, assigning a function typed as F2 to another function typed as F1, then Typescript will complain.

let f1: F1 = () => {
    console.log("F1")
}

// this is okay
let f2: F2 = f1;

// this will error
let f3: F1 = f2;
//   ^ Type 'F2' is not assignable to type 'F1'

With the F2 type having a required input parameter - input1 - it makes sense since the F1 type doesn’t have any parameters.

Optional Parameters

If we made the input1 parameter optional for the F2 function, then typescript would stop complaining.

type F1 = () => void;
type F2 = (input1?: string) => void;

let f1: F1 = () => {
    console.log("F1")
}

// this is okay
let f2: F2 = f1;

// this is okay now
let f3: F1 = f2;

This behavior is also mirrored from Javascript behavior, and since optional parameters are undefined when they are not supplied/provided in Javascript, hence why Typescript allows this behavior. This behavior is unsound from a type-system perspective. Still, one that is allowed by the Typescript Type System, which has to take into account the runtime behavior of Javascript, and this is why the Typescript system is said to be unsound; I will explore this in a future issue.

Conclusion

In this week’s scoop, we covered structural typing in functions. Understanding this behavior is essential when writing and reading Typescript code, and it will help you form a much better mental model for what to expect from Typescript as you continue working with it.

Subscribe now

What does the strict TS Config Compiler Option do?

This single option enables stricter type checks of your Typescript codebase for much better Type safety. These options can be enabled and disabled for each individual option, but with the strict compiler option, you toggle all of them with a single compiler flag.

Another point to note about the strict compiler option is that future versions of Typescript may introduce stricter checking, and by using strict , you will be opting for those as well. Keep that in mind when upgrading to newer versions of Typescript.

What compiler options does strict flag enable?

• alwaysStrict - This ensures that your TS files are parsed in the ECMAScript strict mode, and typescript will emit “use strict” for each source file after transpilation.

• strictNullChecks - Ensures that null and undefined are treated as their own types instead of being effectively ignored. This forces you to handle any null or undefined values before being used.

• strictBindCallApply - It ensures that built-in methods of functions call, bind, and apply are called with the correct arguments for the underlying function.

• strictFunctionTypes - Ensures that function parameters are checked more strictly.

• strictPropertyInitialization - Ensure that class properties are set in the constructor.

• noImplicitAny - When false, typescript will implicitly infer some types as any when no annotations are present. Turning on this ensures you Typescript will implicitly infer a type as any which can compromise type safety as the any type can spill over to other areas of code quite easily.

• noImplicitThis - Throws an error when this expression is inferred as the any type.

• useUnknownInCatchVariable - Instead of using any for the type of an error inside the catch statement, Typescript will use unknown, allowing for a more comprehensive error handling.

What do you think about the strict compiler option?

Leave a comment

Share

Typescript doesn’t always check for excess properties in an object. Understanding when Typescript will check for excess properties is crucial as it helps you know what to expect from Typescript under different conditions.

Let’s start with the following type:

type Person {

firstName: string;

lastName: string;

}

If we created a new variable and typed it as Person, any excess properties in the object will be checked, and Typescript will throw an error.

const x: Person = {

    firstName: "John",

    lastName: "Doe",

    age: 13,

}

In this case, you are going to get the following error:

And this makes sense and is expected because our type Person doesn’t contain the age property.

But, there are some situations where Typescript will remain silent when excess properties are available in an object.

Let’s explore which situations are those.

The first situation is when you introduce an object with the excess fields and assign it to a variable typed as Person.

const x = {

    firstName: "John",

    lastName: "Doe",

    age: 13,

}

const y: Person = x;

In this case, Typescript won’t check for excess properties as type Person is a subset of the type inferred for variable x, which is inferred to include all properties in Person plus age. This is known as duck-typing or structural typing, which I will look at later.

"If it walks like a duck and it quacks like a duck, then it must be a duck"

And in the second situation, when you use an assertion, this doesn’t trigger excess property checking in Typescript.

const x = {

    firstName: "John",

    lastName: "Doe",

    age: 13,

} as Person;

Conclusion

To recap, excess property checking is only triggered when we define object literals with a type annotation and not in other cases. So, why do we have it? It can be very useful for catching wrong typos and wrong property names. This means it’s very limited in scope and understanding when Typescript will check for excess properties and when it will not is essential for building a better mental model for understanding and using Typescript.