Errata

In the type definition, you wrote the following type signature:

type WarnUser = {
(warning: string): void
wasCalled: boolean
}

After that, in the following code, you did not provide, wasCalled argument:

let warnUser: WarnUser = (warning: string) => {
if (warnUser.wasCalled) {
return
}
warnUser.wasCalled = true
alert(warning)
}
warnUser.wasCalled = false

It gives the following squiggly:
Property 'wasCalled' is missing in type '(warning: string) => void' but required in type 'WarnUser'.ts(2741)

I think you meant to declare wasCalled as an optional parameter in the type signature.

type WarnUser = {
(warning: string): void
wasCalled?: boolean
}

Note from the Author or Editor:
A typo on page 64 incorrectly assigns an explicit type annotation to the warnUser function, and claims that assigning an additional property to that function would not lead to a TypeError. This would have been correct, were it not for that explicit type annotation.

Corrected text is here: https://gist.github.com/bcherny/37bac064b151451f4858e0ae28d3ee5b.

A footnote says:

"A handful of languages — Scala, PHP, Kotlin, and Rust, to name a few — implement a pared-down version of mixins, called traits. Traits are like mixins, but don’t have constructors and don’t support instance properties."

I don't think "don't support instance properties" is actually a property of traits. PHP traits do support instance properties, for example.

Note from the Author or Editor:
PHP traits indeed support instance properties.

Traits vs. Mixins is a finicky topic, where implementations are all over the place, and rarely conform to the concepts as originally defined (Traits by Scharli et. al. in 2003, and Mixins by Bracha et. al. in his legendary 1990 paper).

Let's remove the footnote from this book ("A handful of... and the base class."), in order to take a more egalitarian view of Mixins vs. Traits: while they might differ on paper, they're often used interchangeably in practice.

"Since the Command type is a discriminated union type (see [[ discriminated unions]])"

"discriminated unions" looks like it's supposed to be link to another section of the book, instead of being written with brackets around it like " [[ discriminated unions]]"

Note from the Author or Editor:
This is a missing cross-reference. "[[discriminated unions]]" should be a cross-reference to the section on "Discriminated union types".

useState < number[] >;([])).

This code has a misplaced semicolon

Note from the Author or Editor:
This is indeed a typo. It should be changed from:

Before: (e.g., with useState<number[]>;([]))
After (backticks indicate code): (e.g., with `useState<number[]>([])`)

In the following:

let myEvent: Event<HTMLButtonElement | null> = {
target: document.querySelector('#myButton'),
type: 'click'
}

Should the type 'Event' be 'MyEvent'?

Note from the Author or Editor:
Great catch - this should be “MyEvent”, rather than “Event”.

With the code as is, the output, for me, of user.debug() is

Function({"id":3,"name":"Emma Gluzman"})

However, when I change the following line:

let Name = Class.constructor.name

to

let Name = this.constructor.name

then I get the following output:

HardToDebugUser({"id":3,"name":"Emma Gluzman"})

Was this the idea or is there a way for the output to actually be:

User({"id":3,"name":"Emma Gluzman"}) ?

Note from the Author or Editor:
This is a great catch! Let's make two minor updates:

1. On page 103, update `let Name = Class.constructor.name` to `let Name = this.constructor.name`
2. On page 104, update `user.debug() // evaluates to 'User({"id": 3, "name": "Emma Gluzman"})'` to `user.debug() // evaluates to 'HardToDebugUser({"id": 3, "name": "Emma Gluzman"})'`

The following code from the book:

type Currency = {   
unit: 'EUR' | 'GBP' | 'JPY' | 'USD'   
value: number
}

let Currency = {   
DEFAULT: 'USD',   
from(value: number, unit = Currency.DEFAULT): Currency {     
return {unit, value}   
}
}

gives me the following errors:

index.ts(6,5): error TS7022: 'Currency' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

index.ts(8,23): error TS7022: 'unit' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.



But when I turn 'strict' mode off in tsconfig.json, then it compiles...

Note from the Author or Editor:
This is a really great catch. I made the mistake of compiling this without strict mode enabled.

The corrected code is here. Callouts should remain as-is: https://gist.github.com/bcherny/3e73b5c8da3c5a85ed1448c4a33222b8

In this example:
```
import 'react' 1

declare module 'react' { 2
interface Component<P, S> { 3
reducer(action: object, state: S): S 4
}
}
```

Annotation (1) after it says:
"We import 'react', switching our extension file into SCRIPT MODE, which we need to be in to consume a React module. Note that there are other ways we could have switched to script mode, like importing something else, exporting something, or exporting an empty object (export {})—we didn’t have to import 'react' specifically."

I believe since it's using a import, it's switching the extension into MODULE MODE?
At least that's how I understand this part in Chapter "Module Mode Versus Script Mode":
"does your file have any imports or exports? If so, it uses module mode; otherwise, it uses script mode."
?

Note from the Author or Editor:
Confirmed -- this is a typo. We should update each usage of "script mode" to "module mode" in the paragraph at the bottom of 280:

Before: We import 'react', switching our extension file into script mode, which we need to be in to consume a React module. Note that there are other ways we could have switched to script mode, like importing something else, exporting something, or exporting an empty object (export {})—we didn’t have to import 'react' specifically.

After: We import 'react', switching our extension file into module mode, which we need to be in to consume a React module. Note that there are other ways we could have switched to module mode, like importing something else, exporting something, or exporting an empty object (export {})—we didn’t have to import 'react' specifically.

"In other words, numbers is an iterator"

should read

"In other words, numbers is an iterable"

shouldn't it? Numbers is an iterable; it doesn't produce an actual iterator until you pass it to array spread, a for of loop, etc.

(sorry for the double post - I submitted with page 64 originally, not 54, which is correct. Please delete my original post if possible).

Note from the Author or Editor:
Accepted.

Before: "In other words, `numbers` is an iterator..."
After: "In other words, `numbers` is an iterable..."

In the code example in question, the type of the Promise when not explicitly annotated is stated to be inferred to be {}, but in fact it is inferred to be of type unknown (as of version 4.6.4 of Typescript, which is the latest version at the time of writing).

Note from the Author or Editor:
Hey, thanks for the report! Fun fact: this is actually a fix the TypeScript team landed in response to this chapter of the book. See https://github.com/microsoft/TypeScript/issues/27288

Look for the updated error in the next edition of the book!

----

Edits to make:

1. In the code block, update "// Inferred as {}" to "// Inferred as unknown"
2. In the code block, update "// Error TS2362: The left-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint', or an enum type." to "// Error TS2571: Object is of type 'unknown'."
3. In the text below the code block, replace "{}" with "unknown" (using code font): "What gives? Why did TypeScript infer result to be {}? Because we didn’t give it enough information to work with—since TypeScript only uses the types of a generic function’s arguments to infer a generic’s type, it defaulted T to {}!" -> "What gives? Why did TypeScript infer result to be unknown? Because we didn’t give it enough information to work with—since TypeScript only uses the types of a generic function’s arguments to infer a generic’s type, it defaulted T to unknown!"

In bullet #2 all references to 'Piece' should be changed to 'Position'.

Note from the Author or Editor:
Confirmed. We should update all instances of "Piece" in that bullet to "Position", keeping the code font.

It is not true that without the distributive property, the Without type would resolve to never. Here's how it would simplify:

Without<boolean | number | string, boolean>
= (boolean | number | string) extends boolean ? never : (boolean | number | string)
= boolean | number | string

Note that boolean | number | string is not assignable to boolean, hence we follow the false path of the ternary operator.

Note from the Author or Editor:
Thank you for the correction! The suggestion is right.

On page 145:

Before: we would have ended up with `never`
After: we would have ended up with `boolean | number | string`

Class Some<T> extends the interface Option<T>, but since Option<T> is an interface, it cannot be extended, it can only be implemented, therefore the code should read "class Some<T> implements Option<T>".

Note from the Author or Editor:
Hey, thank you for taking the time to report this mistake. Funny it took so long to spot it :) Look for the fix in the next edition of Programming TypeScript, and hope you're enjoying the book!

Boris

-----

Edits to make: in the code example --

1. Update "class Some<T> extends Option<T>" to "class Some<T> implements Option<T>"
2. Update "class None extends Option<never>" to "class None implements Option<never>"

"Files that contain JSX use the file extension .jsx".
should be
Files that contain JSX *can* use the file extension .jsx".

It works fine to use the file extension ".js" for files that contain JSX and many developers do that.

Note from the Author or Editor:
This is technically right -- people sometimes parse .js files using a JSX parser.

Let's change the language on page 202 from:

Before: "Files that contain JSX use the file extension"
After: "Files that contain JSX often use the file extension"