Empty object is valid for non exact type annotation

[diverpb]

Flow version: 0.128.0

Expected behavior

Type error

Actual behavior

const someObj: { id: number } = {};
const num: number = someObj.id;
console.log(num);

num here is undefined, and definitely not a number

• Link to Try-Flow or Github repo:
  https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoAxnAdgZwC5g5wC2ApgPIBGAVgFxgDeYAlgCb1YCuxlpATmAC+YALyNBAbgzZ8YLsQ7deAsUTJVqAOjYSgA

[jcready]

This is just how unsealed objects work in Flow.

[levenleven]

@jcready How is this related to sealed/unsealed if the type is explicitly specified? Also if it would be unsealed the following would be allowed:

const someObj: { id: number } = {};
someObj.foo = 'foo';

but it is not https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoAxnAdgZwC5g5wC2ApgPIBGAVgFxgDeYAlgCb1YCuxlpATmAC+YALyNBAblREyVagDoocOKLAByJXDUSgA

[dsainati1]

Annotating the type of someObj limits what you can do with it. When initializing someObj, you write an unsealed object to the variable, but then tell Flow you only want to allow it to be used as if it is a value of type {id : number}. So the unsealedness of the empty object literal is masked by the fact that you are immediately annotating the value you are assigning it to.

[levenleven]

Thanks @dsainati1 this makes it clearer. (I still feel like it is not desired behavior)

[dsainati1]

Agreed. We have wanted to get rid of unsealed objects for a while, the difficulty is devising a new way to support the existing pattern of building up an object over time.

[achepukov]

related SO question https://stackoverflow.com/questions/62753857/typed-unsealed-object-does-not-allow-new-props

[jcready]

See #7424

[gkz]

Fixed if you enabled exact_empty_objects=true in your .flowconfig.
Announcement will be in the future