Would be nice to have pagination support in gh-got so consumers don't have to implement it themselves

The Github API returns error information in the body as encoded json, it would be nice to get better error messages by using this information.

e.g.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

currently results in:

HTTPError: Response code 400 (Bad Request)

would be nice to get something like:

GithubError: Problems parsing JSON (400)

this passing noop function to got is weird and okey I understand why is it, but break some things sometimes. I think better would be to have silent or mute option and pass it if you dont want to catch the things.

I wanted to add a test but I'm not sure exactly what direction to take since POST requests usually modify remote state. My current ideas are

• Edit a gist that we create specifically for this
• Post a reaction to a specific comment
• Start an HTTP server, set endpoint to localhost:randomport and verify that body is JSON
• Use nock or similar to capture the outgoing request

Actually, maybe we want to use Nock in all the tests since it won't require an active connection and token to Github, thoughts?

Fixes #20.

Any endpoint passed via options without trailing slash was failing, because trailing slash was only massaged when passed via env. Refactored to use url.resolve instead of manual replace.

Also, running npm test on master was broken until I added one object destructuring.

Tried via

await ghGot(apiUrl, { token: this._token, method: 'post' })

as well as

await ghGot.post(apiUrl, { token: this._token })

but i get a (node:30976) UnhandledPromiseRejectionWarning: HTTPError: Response code 404 (Not Found)

I wonder if i'm being clumsy or that gh-got does not support this part of the api?

I occasionally use gh-got as a dep for both github.com and GHE apis. I have an env var, GITHUB_ENDPOINT, for the latter. However, this code:

endpoint: env.GITHUB_ENDPOINT ? env.GITHUB_ENDPOINT.replace(/[^/]$/, '$&/') : 'https://api.github.com/'

Assumes that I am always using it. This breaks some use cases. I could look up and install directory based environment managers, but I am wondering if an easier fix would be to ensure that this setting is only called when you send an opt in. Right now, there isn't even an option for that.

How would you deal with this?

As discussed in #19, I skipped formatting the errors in the streaming API. Not sure how you want it documented though so any input on that would be helpful.

Also, feels like the tests fails because of some globals leaking out from the serial tests. Have something changed in ava regarding the order in which the tests are ran.

Fixes #19

Started as a line comment but let's make it an issue and fix/close it.

The readme says clearly:

Can be overridden globally with the GITHUB_TOKEN environment variable.

Same for the endpoint.

Not sure what the logic was, but I think it would be preferable to use the environment variables only when no applicable argument is passed. An application could have a default token (the env.) but for whatever reason use another token on specific calls.

The module, readme and test would have to be updated. It could be considered a major change since it's reversing its meaning.

Fixes #37 Fixes #22

Only use options.token to set options.headers.authorization if that header is current unset.

This covers the case where:

1. User has a GITHUB_TOKEN defined in env
2. User/app has explicitly set an authorization header and is definitely not expecting it to get ignored/overwritten

This is particularly important also for GitHub "Apps" which need to authentication themselves via Bearer not token, so it's impossible to pass that in options.token either.