fix flow errors by annotating null prototypes#1048
Conversation
|
I think this would be easier to understand if you defined a utility type for this in export type ObjMap<T> = { [key: string]: T, __proto__: null };Then you use |
ddd9822 to
271b86b
Compare
271b86b to
aaaa1d3
Compare
|
Fixes and closes #1045. |
|
Looks great! Though I think you may have missed some manual |
|
This has a bit of an unfortunate side effect of having to add any work arounds for this? |
|
@leebyron oops, I only fixed the ones that gave me flow errors at the moment. Do we need to change all of them? @cloudkite I'm not sure to be honest - I was inspired to make these fixes as a hotfix to unblock other tools depending on |
|
This isn't great - we should probably specifically make |
This is a follow up to #1048 which addresses an issue where flow typed resolver functions would need to be aware of the fact that arguments were prototype-less. That's something we maintain for internal usage, but is more burdensome for external use. Instead, this is just more cautious when using these values internally, using hasOwnProperty, but now returns prototypefull objects to user code. Also follows up with a few additional conversions to ObjMap, such that the only remaining uses of `{[string]: mixed}` are for variables and arguments.
This is a follow up to #1048 which addresses an issue where flow typed resolver functions would need to be aware of the fact that arguments were prototype-less. That's something we maintain for internal usage, but is more burdensome for external use. Instead, this is just more cautious when using these values internally, using hasOwnProperty, but now returns prototypefull objects to user code. Also follows up with a few additional conversions to ObjMap, such that the only remaining uses of `{[string]: mixed}` are for variables and arguments.
From
flow@0.55.0, flow started doing a more strictnullprototype check. Fix them by annotating them with: