Spreading to override null produces incorrect inferred object type

[leoselig]

I was able to reproduce this error in a very minimal code snippet:

https://flow.org/try/#0PTAEAEDMBsHsHcBQjIFcB2BjALgS1uqGugBQAOATrGQM4CUoA3ogJCYE3agBuAhtLgAmALiZFYsUQH5OFXOgDmoAL6gAvGMgTR6VNGgAaUADpTlajRUBuRMuTESjcZNAAibAFNOrlXURA

While playing around it seemed to come down with flow inferring the type of the field foo to null and then regarding the spreaded string as a mismatch.

This can be fixed by reversing the order of spreads and default values like so:

https://flow.org/try/#0PTAEAEDMBsHsHcBQjIFcB2BjALgS1uqGugBQAOATrGQM4CUoA3ogJCYE3agBuAhtLgAmALiZFYsUQH5OFXOgDmoAL6gAvGIB02ytRoAacZNC7amyBNAAfK6HSpo0FQG5Ey5MRKMjogETYAU05fFTpEIA

Unfortunately, this comes at the cost of requiring the explicit listing of each potentially overriding field.

This is the most common error in our code base as it is basically showing up everytime when spreading different sets of props into React components in unit tests.

[chisui]

For what it's worth your first example works if you use undefined instead of null. I couldn't find anthing in the docs that says those are treated differently in this case though.

[leoselig]

@chisui Yes, I actually figured that out already. Since I understand ‘?’ to be the idiomatic way of expressing optional values without distinguishing between undefined and null I believe this should be addressed, am I correct?

[chisui]

I think the problem is in the spread itself. It even occures if you use *, any or don't assign the object at all

This is the smallest example I could find of this behavior.

You can also fix this by explicitly casting null to ?string which shouldn't be needed

[villesau]

I think this will fix the issue: #7298

[nmote]

This no longer errors on master