fix(gatsby): add timeout so fetching API info doesn't fail on very slow connections

[KyleAMathews]

I was on an airplane trying to run gatsby develop and bootstrap hung here. I dug around and found adding a timeout fixed it.

[muescha]

M
I am right that the latestApis only used in:

gatsby/packages/gatsby/src/bootstrap/load-plugins/validate.js

Lines 35 to 41 in 194a97c

	const getErrorContext = (badExports, exportType, currentAPIs, latestAPIs) => {
	const entries = badExports.map(ex => {
	return {
	...ex,
	api: latestAPIs[exportType][ex.exportName],
	}
	})

And only in case of error:

gatsby/packages/gatsby/src/bootstrap/load-plugins/validate.js

Lines 106 to 115 in 194a97c

	const context = getErrorContext(
	entries,
	exportType,
	currentAPIs,
	latestAPIs
	)
	reporter.error({
	id: `11329`,
	context,
	})

Errors are not so much here.

That's why I ask:

1. why we need to fetch on every gatsby develop the lastestApis from an external source?
2. would it be enough only in case of error to fetch this data?
   3) why this latestapis need to stay on an external server? --> [feat] Improve experience of introducing new APIs to Gatsby Core #16055

[KyleAMathews]

would it be enough only in case of error to fetch this data?

Good question. @DSchau didn't you add this originally? Thoughts?

[DSchau]

@KyleAMathews yep -> #16105 (comment)

Wouldn't reasonably slow connections short-circuit here and surpass the 1s limit? Perhaps that's OK. (i.e. faster than airplane, slower than "good")

@muescha I like your idea to only fetch these APIs on error. That's a nicer solution.

@KyleAMathews I'll PR some tweaks and get this merged!

[DSchau]

@KyleAMathews I tried a new approach in 4f812d7.

This will only make the API request when bad exports are detected, which seems like a better approach. I added a few tests, and validated locally.

Seems fine and would solve the underlying issue you identified as the API request will no longer be made in bootstrap unless there are bad exports.

[muescha]

in case of timeout:

• it would be not good to have just an fetch timeout error
• it would be good to print then an describing error message about the signature check and the user should byself lookup at the file later - so he can go on and debug and can see easy errors like small typos

[muescha]

Maybe add also some meta data to the apis.json So we can print also infos like:

You are running now gatsby version 2.0 there is a newer version 2.1 available.

[KyleAMathews]

Looks great! Yeah maybe have a timeout of e.g. five seconds. You could still fetch the data on bootstrap but just don't make the call blocking.

[wardpeet]

Added a small comment about unused arg. This looks good, by default axios does not timeout so probably best to add a timeout option like @KyleAMathews mentioned.

[DSchau]

@muescha

it would be not good to have just an fetch timeout error

It falls through to the catch block with ECONABORTED, which will grab the (hopefully cached) or current apis.json.

Maybe add also some meta data to the apis.json So we can print also infos like:

You are running now gatsby version 2.0 there is a newer version 2.1 available.

This is what it does. If you're using an API in a later version of Gatsby (but with an older version) you'll get a prompt as to what version it was introduced in.

I've added a timeout (5s seems fair), this should be good to go.

[DSchau]

Going to merge and publish -- thanks Kyle for tagging me in!

[DSchau]

Successfully published gatsby@2.15.20