Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow types erased for fetch. #29866

Closed
chrisbobbe opened this issue Sep 5, 2020 · 6 comments
Closed

Flow types erased for fetch. #29866

chrisbobbe opened this issue Sep 5, 2020 · 6 comments
Labels
DX Issues concerning how the developer experience can be improved. Flow Resolution: Locked This issue was locked by the bot.

Comments

@chrisbobbe
Copy link

chrisbobbe commented Sep 5, 2020

Description

In a fresh RN v0.63.2 project (the latest, as of writing), some lines in node_modules/react-native/interface.js suppress Flow type-checking for fetch by making it (and Headers, Request, and Response) any.

Like #22590, but the file has since been moved, in e54ecf9. Those lines first appeared in 7141948 (6fe3b2229 on the PR branch). I'm taking @ferrannp's invitation on #22590 to comment further saying the issue hasn't been fixed (though I'm blocked from posting on the same issue). Back then, as now, the issue is certainly not related to one's precise configuration (beyond using Flow instead of not using Flow), and running the repro should confirm that. 😉 Let me know if the repro fails, though.

React Native version:

$ react-native info
info Fetching system and libraries information...
System:
    OS: macOS 10.15.6
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 582.10 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.12.0 - ~/.nvm/versions/node/v12.12.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.11.3 - ~/.nvm/versions/node/v12.12.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.9.3 - /Users/chrisbobbe/.gem/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 13.7, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 23, 25, 26, 27, 28, 29
      Build Tools: 27.0.3, 28.0.3, 29.0.2
      System Images: android-28 | Google Play Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 3.6 AI-192.7142.36.36.6241897
    Xcode: 11.7/11E801a - /usr/bin/xcodebuild
  Languages:
    Java: 1.8.0_212-release - /usr/bin/javac
    Python: 2.7.16 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1 
    react-native: 0.63.2 => 0.63.2 
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

To set up, make a new project with react-native init and run yarn add flow-bin@^0.122.0 (or whichever version is mentioned under [version] in .flowconfig.). Then insert, e.g., fetch('https://www.google.com') in some valid FILE at LINE and COLUMN (e.g., App.js at line 1, column 1)

Then, to see the problem:

Run yarn flow type-at-pos FILE LINE COLUMN (e.g., yarn flow type-at-pos App.js 1 1)

Expected Results

I expect this output:

(input: RequestInfo, init?: RequestOptions) => Promise<Response> (or whatever Flow's internal type definitions have for fetch at the Flow version appropriate for the RN version)

Instead, I get this output:

any (explicit)

If I remove the indicated lines in node_modules/react-native/interface.js and rerun steps 1 and 2 above, I get the expected output.

@react-native-bot react-native-bot added Flow 🌐Networking Related to a networking API. labels Sep 5, 2020
@safaiyeh
Copy link
Contributor

safaiyeh commented Sep 6, 2020

Hi @chrisbobbe thanks for the issue! It seems like you found a quick fix. Do you mind submitting a PR for this for review?

@safaiyeh safaiyeh added DX Issues concerning how the developer experience can be improved. and removed Needs: Triage 🔍 🌐Networking Related to a networking API. labels Sep 6, 2020
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 9, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

It looks like we've gestured toward not allowing `params` to contain
`headers`, so, make that explicit.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
chrisbobbe added a commit to chrisbobbe/react-native that referenced this issue Sep 10, 2020
@chrisbobbe
Copy link
Author

Hi @chrisbobbe thanks for the issue! It seems like you found a quick fix. Do you mind submitting a PR for this for review?

Sure thing! 🙂 Just sent #29926.

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 11, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

It looks like we've gestured toward not allowing `params` to contain
`headers`, so, make that explicit.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
chrisbobbe added a commit to chrisbobbe/react-native that referenced this issue Sep 15, 2020
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 17, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

It looks like we've gestured toward not allowing `params` to contain
`headers`, so, make that explicit.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 17, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

It looks like we've gestured toward not allowing `params` to contain
`headers`, so, make that explicit.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
@chrisbobbe
Copy link
Author

chrisbobbe commented Sep 18, 2020

There's been a small issue with the CLA on my PR #29926 (Facebook has been unresponsive); @safaiyeh, do you mind taking a quick look if you have time? Maybe you've seen the issue before and have some advice on how to proceed? 🙂

Once this is out of the way, there will be a lower barrier for me to make more PRs. 🙂

chrisbobbe added a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 18, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

Also, it looks like the functionality of `getFetchParams` would
break if a caller included `headers`, so make the type not allow
that.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
gnprice pushed a commit to chrisbobbe/zulip-mobile that referenced this issue Sep 18, 2020
With facebook/react-native#29866, `fetch` and a few of the major
things it uses are totally untyped. But react-native doesn't
suppress `RequestOptions` [1], so we can still use that to help make
sure we're passing around the right kinds of stuff that will
eventually be fed to `fetch`.

Also, it looks like the functionality of `getFetchParams` would
break if a caller included `headers`, so make the type not allow
that.

A type-cast and a $FlowFixMe on it at the top of `getFetchParams`
can fall away naturally.

[1] See it at https://www.saltycrane.com/cheat-sheets/flow-type/latest/
@stale
Copy link

stale bot commented Dec 25, 2020

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

@stale stale bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Dec 25, 2020
@chrisbobbe
Copy link
Author

Go away stale-bot, there's no sign this issue has been fixed. 🙂

@stale stale bot removed the Stale There has been a lack of activity on this issue and it may be closed soon. label Dec 25, 2020
@chrisbobbe
Copy link
Author

It looks like this was resolved in 6651b7c. Thanks, @panagosg7!

chrisbobbe referenced this issue Feb 8, 2021
Summary:
The main change of this diff is in file react-native-github/interface.js.
This file used to override the definitions for `fetch`, `Headers`, `Request`,
`Response`, `requestAnimationFrame` of flow/lib/bom.js and type them
as `any` instead.

This is inconsistent with the rest of the flow library definitions that expect
`Request`, for example, to be adequately typed. Overriding this defnition
with `any` raises `[value-as-type]` errors in the library definitions themselves.

Due to a Flow bug, these errors were silently suppressed, leading to loss of
coverage. I'm trying to clean-up these errors and fix the Flow bug so that
library errors are always surfaced.

This diff also:
* Removes 53 unused suppression comments
* Adds 110 new error suppressions

Changelog: [Internal]

Reviewed By: pieterv

Differential Revision: D25806504

fbshipit-source-id: e312bc5d64818b63c3b8b4f86dea51e13aacfac0
@facebook facebook locked as resolved and limited conversation to collaborators Feb 8, 2022
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Feb 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
DX Issues concerning how the developer experience can be improved. Flow Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants