-
Notifications
You must be signed in to change notification settings - Fork 927
Closed
Labels
good first issue: takeninfraInternal work not facing public APIsInternal work not facing public APIs
Description
During the review of #268, we noticed that we are using multiple fetch implementations across the CLI. These are:
fetch
function fromcli/src/tools/fetch.js
. This is a very, very minimalistic GET-only wrapper around the standardhttps
module.httpsGet
function fromcli/src/tools/releaseChecker/getLatestRelease.js
. This is, again, a GET-only wrapper aroundhttps
that exists because the above mentionedfetch
does not satisfies the requirements (see discussion).node-fetch
intools/src/isPackagerRunning.js
.
Should we standardize the way we make HTTP requests in this project?
I propose to discuss and decide on one implementation to use across the entire CLI to keep things consistent. Of course, it doesn't have to be one of the above implementations if you want to suggest a different one (e.g. axios
or the standard https
Node module) 😃
I'll start! I believe we can stick with node-fetch
and replace the other implementations with it. We should also mention somewhere in the Contributing doc to use node-fetch
when making network request so that we avoid this inconsistency happening again in the future.
Metadata
Metadata
Assignees
Labels
good first issue: takeninfraInternal work not facing public APIsInternal work not facing public APIs