Immutable v4 Records, confusing behavior with undefined

[cvlmtg]

What happened

I'm upgrading some projects from immutable 3.8 to immutable 4.0 and have found some confusing behavior when assigning undefined to a Record key. With version 3 it was possibile to set a value to undefined, now it seems it acts as a sort of "reset to default value", which at first is quite confusing.

I see no mention of this behavior on the changelog nor in the documentation, and it's not clear if it's wanted or not. in the first case it should probably be listed as a breaking change imho. (however my opinion is that it should be possible to assign undefined, like in v3)

How to reproduce

V4

Welcome to Node.js v14.17.6.
Type ".help" for more information.
> Immutable = require('immutable'); undefined
undefined
> R = new Immutable.Record({ a: 1, n: null, u: undefined })
[Function: Record]
> r = new R(); console.log(r.toJS())
{ a: 1, n: null, u: undefined }
undefined
> r1 = r.merge({ a: 2, n: 2, u: 2 }); console.log(r1.toJS())
{ a: 2, n: 2, u: 2 }
undefined
> r2 = r1.merge({ a: undefined, n: undefined, u: undefined }); console.log(r2.toJS())
{ a: 1, n: null, u: undefined }
undefined
> r3 = r1.set('n', undefined); console.log(r3.toJS())
{ a: 2, n: null, u: 2 }
undefined
> r4 = r1.set('u', undefined); console.log(r4.toJS())
{ a: 2, n: 2, u: undefined }
undefined
> r5 = r1.set('a', undefined); console.log(r5.toJS())
{ a: 1, n: 2, u: 2 }
undefined
>

V3

Welcome to Node.js v14.17.6.
Type ".help" for more information.
> Immutable = require('immutable'); undefined
undefined
> R = new Immutable.Record({ a: 1, n: null, u: undefined })
[Function: Record]
> r = new R(); console.log(r.toJS())
{ a: 1, n: null, u: undefined }
undefined
> r1 = r.merge({ a: 2, n: 2, u: 2 }); console.log(r1.toJS())
{ a: 2, n: 2, u: 2 }
undefined
> r2 = r1.merge({ a: undefined, n: undefined, u: undefined }); console.log(r2.toJS())
{ a: undefined, n: undefined, u: undefined }
undefined
> r3 = r1.set('n', undefined); console.log(r3.toJS())
{ a: 2, n: undefined, u: 2 }
undefined
> r4 = r1.set('u', undefined); console.log(r4.toJS())
{ a: 2, n: 2, u: undefined }
undefined
> r5 = r1.set('a', undefined); console.log(r5.toJS())
{ a: undefined, n: 2, u: 2 }
undefined
>

[thatsmydoing]

It seems like it is mentioned in the PR for the Record change #1135

This is also a breaking change as delete() (aka remove()) and clear() are no longer available - previously these methods reverted values to their default value, now that can be done with set(k, undefined).

Though it seems delete() and clear() were added back in later #1157

So the change seems intentional, but just wasn't mentioned as a breaking change. And I do also agree it's a bit unintuitive and would prefer the original behavior. Just because a default value isn't undefined doesn't mean we never want to set it to undefined.