Flow: assigning undefined does not error on maybe types

[madole]

My understanding that maybe types can be null | type, when we declare a property, but assign it to be undefined (I know this is bad practice), I would expect flow to complain because now the property value is void 0/undefined.

It looks like this only gets triggered if the value is undeclared.

/* @flow */

type thing = {
  a: number,
  b: ?number,
  c?: number
}

const firstTest: thing = {
  a: 1,
  b: 2
};

const secondTest: thing = {
  a: 1,
  b: null
};

const thisShouldError: thing = {
  a: 1,
  b: undefined
};

let undefinedVariable;

const thisShouldFailAlso: thing = {
  a: 1,
  b: undefinedVariable
};

I've set this test up in the Flow REPL here

[AugustinLF]

A maybe type in flow can also contain undefined!

[madole]

I'm suggesting that : ?number seems to be null | number and ?: number seems to be undefined | number.

Yet if you define a property as undefined, you don't get an error from a property of type : ?number. It's inconsistent.

[AugustinLF]

Based on the doc and the example, : ?number is null | number | undefined. That's why in the example, if you use a strict equal and just check for null, it wants you to also check for undefined.

On a higher level, it does bother me, I find it cumbersome to switch for a ==, and it would be much simpler if it didn't cover undefined, but I guess that it's not possible given the current state of JavaScript.

[jesseschalken]

@AugustinLF I argued at length on the relevant TypeScript issue (https://github.com/Microsoft/TypeScript/issues/7426) that ?T (or T? in TS) should not include undefined, for example because when passed into an optional parameter, undefined is replaced with the default value, while null isn't, which makes for very confusing behaviour if you use them interchangeably, which ?T = T|null|undefined encourages you to do.