TypeScript Roadmap: Enhanced Type System, More Productivity, and Improved Linting

Microsoft has detailed the&nbsp;<a href="https://github.com/Microsoft/TypeScript/issues/29288" target="_blank">priorities that will drive TypeScript development during the first six months of 2019</a>. Albeit not yet committed, the current roadmap includes enhanced core type system, maximizing forward compatibility with&nbsp;<a href="https://github.com/tc39" target="_blank">new ECMA features</a>, improving tools, including editor support and linting, and more.

Microsoft has detailed the priorities that will drive TypeScript development during the first six months of 2019. Albeit not yet committed, the current roadmap includes enhanced core type system, maximizing forward compatibility with new ECMA features, improving tools, including editor support and linting, and more.


On the core type system front, TypeScript keeps its focus on providing a type system that can model JavaScript patterns with the aim to catch bugs and enforce correctness. A new feature of the TypeScript type system will be the ability of “proving relationships between types”, which will allow the compiler to check type correctness when type operators are used.


Special attention will be paid to improving the coexistence of TypeScript and JavaScript. This is mostly due to the growth of the TypeScript user base, with many developers using TypeScript to check or compile their JavaScript code, or transitioning to TypeScript. For example, this will include improvements to the JavaScript editing experience, integration of JSDoc types, making it easier to transition to TypeScript.


Another front where Microsoft will be active is representation within standardization committees, particularly the TC39 committee, which is going to bring the next ECMA standard, and the Node modules group. Highest priority will be influencing the committee's work to ensure better compatibility with proposed features that TypeScript adopted earlier on, such as class fields, decorators, module interoperability, null propagation/coalescing, etc.


Improving tools and developers productivity is also among Microsoft´s goals for the evolution of the TypeScript ecosystem. This includes editor features such as “proactive” quick fixes that will suggest possible changes to improve the code, for example detecting implicit any use even when not using the noImplicitAnycompiler setting and inferring an appropriate type. Improving how developers deal with declaration files is also center stage, with the aim of finding a workflow to help developer handle the case where a type file is not available in DefinitelyTyped or fix erroneous declaration files. Additionally, Microsoft also plans to improve the TypeScript linter (TSLint) performance and the TypeScript server (TSServer) speed, scalability, and stability. Interestingly, to solve TSLint performance issues, Microsoft will leverage ESLint, which they say has the kind of architecture they are striving for, and send contributions to bring its TypeScript support to parity with TSLint.


As a final note, Microsoft is also planning to write a new TypeScript handbook, improve compiler diagnostics, update the TypeScript playground, and extend the DefinitelyTYped infrastructure.

You can get the full details in the official GitHub Roadmap page.

What TypeScript taught me about JavaScript

What TypeScript taught me about JavaScript

What TypeScript taught me about JavaScript. TypeScript was designed to make the most sense out of any JavaScript code. How void behaves in both TypeScript and JavaScript. What Symbols are and why they can be unique. Why substitutability is such an important concept for TypeScript

TypeScript was designed to make the most sense out of any JavaScript code. Given the dynamic nature of JavaScript, this can lead to some very interesting typings that may seem odd at a first glance. In this talk, we will look at JavaScript scenarios that are easy to understand, but complex to define. We then see what tools TypeScript provides to make the most dynamical behaviour predictable, in the most elegant way possible.

Join us and learn:

  • How void behaves in both TypeScript and JavaScript
  • What Symbols are and why they can be unique
  • The constructor interface pattern, and why classes are more complex than you might think
  • Why substitutability is such an important concept for TypeScript
    ... and much more!

Introduction Boolean in JavaScript and TypeScript

Introduction Boolean in JavaScript and TypeScript

Boolean values are supported by both JavaScript and TypeScript and stored as true/false values .This is because, while JavaScript coerces an object to its primitive type, the TypeScript type system does not. TypeScript treats it like an object type.

Boolean in JavaScript

boolean can take the values of true and false. Values from other types can be truthy or falsy, like undefined or null.

let b = true
if(b) console.log('logged')

b = false
if(b) console.log('not logged')

b = undefined
if(b) console.log('not logged')

b = null
if(b) console.log('not logged')

Values other than undefined, null or false considered falsy are "" (empty string), -0 and 0, as well as NaN.

To get the boolean value of any value, you can use the Boolean function:

Boolean(false) // false
Boolean(true) // true
Boolean("false") // true ❗️
Boolean("Hey folks") // true
Boolean({}) // true
Boolean([]) // true
Boolean(123.4) // true
Boolean(Symbol()) // true
Boolean(function() {}) // true
Boolean(undefined) // false
Boolean(null) // false
Boolean(NaN) // false
Boolean(0) // false
Boolean("") // false

Rule of thumb: All empty values evaluate to false. Empty object {} and empty array [] (which is an object itself) do have value as they are containers for other values.

The Boolean function is really good to filter empty values from collections:

const collection = [
  { name: 'Stefan Baumgartner', age: 37 },
  undefined,
  { name: 'D.', age: 36 },
  false
  { name: 'C.', age: 2},
  false
]

collection.filter(Boolean) // handy!

Together with Number – which converts all values into their number counterpart or NaN, this is a really cool way of getting to actual values quickly:

const x = ["1.23", 2137123, "wut", false, "lol", undefined, null]
  .map(Number)
  .filter(Boolean) // [1.23, 2137123] 👍

Boolean exists as a constructor and has the same conversion rules as the Boolean function. However, with new Boolean(...) you create a wrapping object, making value comparisions truthy, but reference comparisions falsy:

const value = Boolean("Stefan") // true
const reference = new Boolean("Stefan") // [Boolean: true]

value == reference // true
value === reference // false

You get to the value via .valueOf():

value === reference.valueOf() // true

I have a REPL for you to check. The use of Boolean as a function is obviously great, but new Boolean has very limited use. If you know a practical use case, please let me know.

Boolean in TypeScript

boolean in TypeScript is a primitive type. Be sure to use the lower case version and don’t refer to
object instances from Boolean

const boolLiteral: boolean = false // 👍
const boolObject: Boolean = false // 👎

It works, but it’s bad practice as we really rarely need new Boolean objects.

You can assign true, false and undefined and null to boolean in TypeScript without strict null checks.

const boolTrue: boolean = true // 👍
const boolFalse: boolean = false // 👍
const boolUndefined: boolean = undefined // 👍
const boolNull: boolean = null // 👍

With that, boolean is the only one we can express fully through union types:

type MyBoolean = true | false | null | undefined // same as boolean

const mybool: MyBoolean = true
const yourbool: boolean = false

When we enable the strictNullChecks compiler flag, the set of values reduces to true and false.

const boolTrue: boolean = true // 👍
const boolFalse: boolean = false // 👍
const boolUndefined: boolean = undefined // 💥
const boolNull: boolean = null // 💥

So our set reduces to two values in total.

type MyStrictBoolean = true | false

We can also get rid of null values with the NonNullable helper type:

type NonNullable<T> = T extends null | undefined
  ? never
  : T;

type MyStrictBoolean = NonNullable<MyBoolean> // true | false

The fact that boolean consists of a limited set of values only used in conditions, allows for interesting conditional types.

Think of an mutation in a datastore through a function. You set a flag in a function that updates e.g. the user id. You have to provide the user ID then:

type CheckUserId<Properties, AddUserId> = 
    AddUserId extends true 
    ? Properties & { userId: string }
    : Properties & { userId?: string }

Depending on the value of our generic AddUserId, we expect the property userId to be set or to be optional.

We can make this type more explicit by extending our generics from the types we expect

- type CheckUserId<Properties, AddUserId> = 
+ type CheckuserId<
+  Properties extends {},
+  AddUserId extends boolean
+ >
     AddUserId extends true 
     ? Properties & { userId: string }
     : Properties & { userId?: string }

In use, it might declare a function like this:

declare function mutate<P, A extends boolean = false>
  (props: CheckUserId<P, A>, addUserId?: A): void

Note that I even set a default value for A to make sure CheckUserId gives the correct info depending on addUserId to be set or not.

The function in action:

mutate({}) // 👍
mutate({ data: 'Hello folks' }) // 👍
mutate({ name: 'Stefan' }, false) // 👍
mutate({ name: 'Stefan' }, true) // 💥 userId is missing
mutate({ name: 'Stefan', userId: 'asdf' }, true) // 👍 userId is here

Handy if your code relies a lot on truthy and falsy values. As always, there’s playground for you.

Originally published at fettblog.eu on 10 September 2019

Understanding void in JavaScript and TypeScript

Understanding void in JavaScript and TypeScript

void exists in both JavaScript as an operator and in TypeScript as a primitive type. And in both worlds void works a little bit different than most people are used to.

If you come from traditional, strongly typed languages you might be familiar with the concept of void: A type telling you that functions and methods return nothing when called.

void in JavaScript

void in JavaScript is an operator which evaluates the expression next to it. No matter which expression is evaluated, void always returns undefined.

let i = void 2; // i === undefined

Why would we need something like this? First, in earlier times, people were able to override undefined and giving it an actual value. void always returned the real undefined.

Second, it’s a nice way to call immediately invoked functions:

void function() {
  console.log('What')
}()

All without polluting the global namespace:

void function aRecursion(i) {
  if(i > 0) {
    console.log(i--)
    aRecursion(i)
  }
}(3)

console.log(typeof aRecursion) // undefined

Since void always returns undefined, and void always evaluates the expression next to it, you have a very terse way of returning from a function without returning a value, but still calling a callback for example:

// returning something else than undefined would crash the app
function middleware(nextCallback) {
  if(conditionApplies()) {
    return void nextCallback();
  }
}

Which brings me to the most important use case of void: It’s a security gate for your app. When your function is always supposed to return undefined, you can make sure that this is always the case.

button.onclick = () => void doSomething();

void in TypeScript

void in TypeScript is a subtype of undefined. Functions in JavaScript always return something. Either it’s a value, or undefined

function iHaveNoReturnValue(i) {
  console.log(i)
} // returns undefined

Since functions without a return value always return undefined, and void always returns undefined in JavaScript, void in TypeScript is a proper type for telling developers that this function returns undefined:

declare function iHaveNoReturnValue(i: number): void

void as type can also be used for parameters and all other declarations. The only value that can be passed is undefined:

declare function iTakeNoParameters(x: void): void

iTakeNoParameters() // 👍
iTakeNoParameters(undefined) // 👍
iTakeNoParameters(void 2) // 👍

So void and undefined are pretty much the same. There’s one little difference though, and this difference is significant: void as a return type can be substituted with different types, to allow for advanced callback patterns:

function doSomething(callback: () => void) {
  let c = callback() // at this position, callback always returns undefined
  //c is also of type undefiend
}

// this function returns a number
function aNumberCallback(): number {
  return 2;
}

// works 👍 type safety is ensured in doSometing
doSomething(aNumberCallback) 

This is desired behaviour and often used in JavaScript applications. Read more on this pattern called substitutability in my other articles.

If you want to make sure to pass functions who only return undefined (as in “nothing”), be sure to adapt your callback method signature:

- function doSomething(callback: () => void) {
+ function doSomething(callback: () => undefined) { /* ... */ }

function aNumberCallback(): number { return 2; }

// 💥 types don't match
doSomething(aNumberCallback)

You’ll propably be good with void most of the time.

Originally published at fettblog.eu on 06 September 2019