`Option<String>` generates `string | undefined` as type instead of `string | null`

[chris13524]

The examples here cover scenarios where I add 1 of 3 different attributes to my optional field to make it generate ? or | undefined.

However, I'm not adding any attributes. Serde's normal behavior with an Option is to allow it to be null. However, if a field isn't supplied (set to undefined in JS) then serde will fail when it doesn't have the field it expects.

To summarize, if my field is just a normal Option<String> with no fallback for the missing value, so tsify should generate string | null to be accurate to serde's behavior.

[chris13524]

Actually, it looks like switching from js to json feature will make this (almost, there shouldn't be the ? either) as I would expect:

tsify/tests/optional.rs

Line 132 in dfc1d32

c?: number | null;

Why is this behavior different? IMO None should map to null by default regardless of the underlying binding technology.

[siefkenj]

Interesting. Javascript's two null types strike again...I'm not sure the best thing to do, since I'm not sure what types people are relying on now...