Consistently use undefined instead of mixed null and undefined

[faustbrian]

• Additional lint rules to consider #1935 (comment)
• Intent to stop using `null` in my JS code sindresorhus/meta#7
• https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined
• Rule proposal: no-null eslint/eslint#6701
• https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=561s

What I mean by mistake is that generally null and undefined mean the same thing and people mostly argue semantics that undefined means uninitialised and null means currently unavailable but both of those are the same thing in terms of code, an empty state. It's basically the whole null-pointer billion-dollar mistake reasoning but also consistency because you don't want to introduce multiple values that have the same meaning.

This sindresorhus/meta#7 is a good read and lists quite a few reasons why you should ditch null in your code. TypeScript itself also doesn't use null and denotes everything undefined with undefined and the Microsoft style-guide also tells developers to use undefined. Also a fun snippet to show how null can trip you up

❯ node
Welcome to Node.js v16.16.0.
Type ".help" for more information.
> typeof null
'object'
> typeof undefined
'undefined'

[gabrocheleau]

Not necessarily against this, but two things come to mind:

• To my knowledge, JSON only supports null and not undefined. Our repo is heavily reliant on .json files for configuration, testing, etc. What do you think would be the best way to handle this?
• In my view, null stands for "defined" empty, while undefined is "undefined" empty (at least that's how I try to use it). Would be good to investigate how much (if any) information loss would occur if we discard null completely in favor of undefined.

[faustbrian]

For JSON parsing I usually use a custom JSON.parse function that handles that and then also a custom JSON.stringify that handles the inverse.

JSON.parse('{"key":null}', (_, value) => {
    if (value === null) {
        return undefined
    }

    return value;
})

Point 2 is exactly the semantics point I mentioned in the initial post 😅 People argue about those but they're never consistently enforced and top of that null has lot of funny side-effects and odd behaviours liketypeof null === 'object'whiletypeof undefined === 'undefined'` makes a whole lot more sense and indicates the same thing (empty state) without any ambiguity.

Most code in this repository is rather sketchy to use with pure JS anyway (due to mostly doing TS-specific type checks rather than run-time type checks) so types will already aid you in knowing if a property is actually non-existent or if it is specified on the implementation contract but currently empty.