chore(gatsby): Fix case where the error parser receives an array

[pvdz]

The repro was too big to wrap in a test, but I did debug this to a point where I've verified and observed in the devtools that this value was an array. As such I'm adding a check and taking the first element of that array.

Technically there could be multiple errors in that array and perhaps we should do something with that. As it stands, printing an error is better than printing "cannot call match on undefined" :)

[bball07]

Thank you for your contribution!! I am going to merge this :)

[muescha]

is this PR fixing this error?

I (kind of) have the same error:

TypeError: Cannot read property 'match' of undefined
  
  - api-runner-node-error-parser.js:39 errorParser
    [front-end]/[gatsby]/dist/utils/api-runner-node-error-parser.js:39:33
  
  - api-runner-node.js:398 
    [front-end]/[gatsby]/dist/utils/api-runner-node.js:398:29

But applying the changes from this PR doesn't seem to fix it... Would you an idea?

Thanks in advance

Originally posted by @adrienharnay in #20517 (comment)

( Note: api-runner-node-error-parser.js was renamed to api-runner-error-parser.js)

[pvdz]

Might be. Hard to tell from the description.

[g00glen00b]

In my case, it didn't resolve the issue. I accidentally deleted the icon referenced within the gatsby-plugin-manifest configuration. However, it seems that the error being thrown by the plugin is a string.

This caused err to be a string itself. And thus, err.message to be undefined. This code-change does fix the error.
However, since matched is still false, structured will be undefined. This causes issues later on in api-runner-node.js, where structuredError.context is accessed.

I hope this was helpful.

[pvdz]

@g00glen00b That sounds reasonable. I've opened #20909 to work around that problem as well. Thank you :)