Provide custom onError handler for http-proxy-middleware

[cloudmu]

This will change the http-proxy-middle logLevel option from 'silent' to 'error' in development mode.

Errors are bound to occur when proxying API requests to an API server during development, for various reasons such as forgetting to start the API server or using an incorrect port. With 'silent' option, no error message will be shown in the command line console at all, which can be confusing. With 'error' option, the console will show a very concise and informative error message, which helps to quickly pinpoint to the issues.

For example, following is an example of the error message (caused by not starting the API server) in the command line console:

[gaearon]

This error message looks very confusing and aggressive. Can we improve the error output of this Node module first, to be readable in common cases?

[cloudmu]

Personally I think the error message (as is) might still be better than being silent. It gives some hints, such as keyword "Proxy Error", standard POSIX error code, and the hostname and targetUri the proxy failed to access. However I totally understand the concern and CRA's principled approach of being beginner friendly.

I looked into how the error messages (with error codes such as ECONNREFUSED) is formulated:

1. http-proxy-middleware (a.k.a. HPM) simply prints out the error code thrown from another lib http-proxy.
   See the logError impl here
   logger.error('[HPM] PROXY ERROR: %s. %s -> %s', err.code, hostname, targetUri);
2. http-proxy in turn gets the error code thrown from Node.js. See Node Common System Errors
   Note it's great that for each error code, there is corresponding explanation in plain text (which would be great if CRA can refer to).
3. To further trace back to the origin (not that we need to worry here, but just for completeness), the Common System Errors are ultimately generated from within the runtime environment at syscall level, See errno

So as @gaearon suggested, the straightforward approach may be to improve the error output in http-proxy-middleware (or http-proxy). The logError implementation can simply reference the NodeJS common System Error page (as a link), and/or print out the plain text explanations mapped to the common errors such as ECONNREFUSED, ECONNRESET, and ETIMEDOUT.

[geowarin]

Errno is a cool npm package for the purpose of translating node's errors

[gaearon]

So as @gaearon suggested, the straightforward approach may be to improve the error output in http-proxy-middleware (or http-proxy). The logError implementation can simply reference the NodeJS common System Error page (as a link), and/or print out the plain text explanations mapped to the common errors such as ECONNREFUSED, ECONNRESET, and ETIMEDOUT.

Errno is a cool npm package for the purpose of translating node's errors

Sounds good to me, would you like to send a PR to http-proxy-middleware?

[cloudmu]

Yes I can do a PR to http-proxy-middleware.
Unfortunately Errno would only provide a very simple description by default. E.g. "connection refused" for "ECONNREFUSED".

So we can either

1. further customize the Errno description by using the text from Node Common System Error
   or
2. reference the Node Common System Error as a html link directly in the console error log.

Any preference?

[gaearon]

We decided to update this to use onError, is that correct?

[cloudmu]

@gaearon Yes we decided to use onError. Just got around to implement it. Two options with slight differences.
1 No chalk color used:

2 Cyan color for url and links:

Any preference? I will check in code later on.

[gaearon]

Let’s make it An error instead of Error, keep cyan, and additionally highlight the error type with red.

[cloudmu]

Like this?

[gaearon]

Hmm. It’s still a bit too easy to miss it.

Maybe try <red>Proxy error:</red> Could not proxy request ...?
I think worth trying a few different variations.

[cloudmu]

Like the suggestion. It reads better, and makes Proxy error more obvious.

To nitpick, we can keep error code plain, to make the console a little less busy.

Pick one :-)

[gaearon]

This looks good.

[gaearon]

Let’s do the second one. I would probably remove cyan from Node docs link and maybe add cyan to the error code instead. Also could try putting the whole second line into chalk.dim.

[cloudmu]

I will go with this for now.

chalk.dim works on Mac, but not on Windows 10 (in my testing).

[gaearon]

Beautiful work. Thanks.

[gaearon]

Out in 0.4.1!

[lileilei]

http-party/node-http-proxy#579 Look at this issue!