In the READMe.md file, your sample code uses a zero-argument constructor for the esiJS class:

const esiJS = require('esijs')
const esiClient = new esiJS()

This generates a TypeError: Cannot read property 'logging' of undefined because you need to instantiate using something like:

const esiJS = require('esijs')
const esiClient = new esiJS({logging: false})

The sample code in the 'How To Install esiJS' wiki page is also wrong (and still has require('esiJS') too).

Had a few immediate failures when pulling this in. Here they are (simple fixes?):

/node_modules/esijs/Functions/utility.js:24
        let path = 'latest v1 legacy dev'.split(' ')
            ^

SyntaxError: Identifier 'path' has already been declared

and

internal/modules/cjs/loader.js:797
    throw err;
    ^

Error: Cannot find module './Functions/killmails'
Require stack:
- /.../node_modules/esijs/endpoints.js
...

(node:26643) UnhandledPromiseRejectionWarning: ReferenceError: categoryID is not defined
Code seems to be taking the wrong input:

constellationInfo (constellationID) {
    inputValidation({ input: categoryID, type: 'number', message: `The function 'universe.constellations.constellationInfo requires a constellation Id!` })
    
    return request({ subUrl: `universe/constellations/${constellationID}` })
},

^ This one is fixed in this Pull Request: #8

Is there a way to make authenticated requests?

In endpoints.js, killMails.js is imported as killmails: require('./Functions/killMails'),. The version available on npm has the file kill mails cased as killmails.js resulting in not node/webpack being able to import the file. The file is correctly typed within the source code though which leads me to believe it is related to the build system used. As such I don't think I am able to fix this with a pr, what build system are you using?

Some ESI requests have you pass data via a payload instead of like a URL parameter. From what I can tell, the caching system at the moment is based on a fullURL that is assembled here:

Since that method doesn't account for payload parameters, it can cause the caching to return results from previous queries even though the parameters have changed.

The most blatant case of this that I have encountered thus far is with the universe.bulk.idsToNames endpoint as it takes an array of IDs as a payload. Making a second request before the cache times out causes it to return the previous results... which is incorrect.

Side note, my use case for this library is personal and I have explicit control over being respectful of ESI. So for my uses, I don't need a cache. As such I'm going to fork this library and modify it as needed for my own shenanigans. So this bug isn't a blocker for me personally, but I wanted to log it anyway.

The alliance group has an entry for corps that seems to be set up wrong.

It is attempting to send a request to a alliances/${allianceID}/alliances endpoint which doesn't exist.

I believe this needs to be updated to point at the /alliances/${corporationID}/corporations/ ESI route instead.

The corporation group has an entry for corporationHistory that seems to be set up wrong.

The comment seems to acknowledge that this is meant to be for the corporation's alliance history, but it is named wrong and attempts to send a request to a corporations/${corporationID}/corporationhistory endpoint which doesn't exist.

I believe this may be a copy-paste error and needs to be updated to point at the /corporations/${corporationID}/alliancehistory/ ESI route instead.

I was trying out your library and I think I found a bug in the example.

The following resulted in "MODULE NOT FOUND".

const esiJS = require('esiJS')

Had to change it to:

const esiJS = require('esijs')

My platform is Ubuntu btw.

If you agree I can make a PR.

The input validation requires it to be an object then the value is string