Does callback guarantee promise resolved or rejected in ES6 class constructor?

Question

I'm having trouble to understand why using a callback, which always returns an empty object. And pass the param to this callback.

https://github.com/ghdna/cognito-express/blob/master/lib/strategy.js#L20

I'm assuming this guarantee the Promise is either resolved or rejected.

class CognitoExpress {
    constructor(config) {
        if (!config)
            throw new TypeError(
                "Options not found. Please refer to README for usage example at https://github.com/ghdna/cognito-express"
            );

        if (configurationIsCorrect(config)) {
            this.userPoolId = config.cognitoUserPoolId;
            this.tokenUse = config.tokenUse;
            this.tokenExpiration = config.tokenExpiration || 3600000;
            this.iss = `https://cognito-idp.${config.region}.amazonaws.com/${this
                .userPoolId}`;
            this.promise = this.init(callback => {});
        }
    }

    init(callback) {
        return request(`${this.iss}/.well-known/jwks.json`)
            .then(response => {
                this.pems = {};
                let keys = JSON.parse(response)["keys"];
                for (let i = 0; i < keys.length; i++) {
                    let key_id = keys[i].kid;
                    let modulus = keys[i].n;
                    let exponent = keys[i].e;
                    let key_type = keys[i].kty;
                    let jwk = { kty: key_type, n: modulus, e: exponent };
                    let pem = jwkToPem(jwk);
                    this.pems[key_id] = pem;
                }
                callback(true);
            })
            .catch(err => {
                callback(false);
                throw new TypeError(
                    "Unable to generate certificate due to \n" + err
                );
            });
    }

Answer 1

In your own code you would never do that: once you use promises, there is no gain in using the old-style callback system.

Apparently the author of this API wanted to offer both callback-based and promise-based support via the init method, so that the client of that API could still choose, or maintain compatibility with a previous version of this API which might have only supported the callback-style.

Now the init method takes a required callback argument: if it would not be passed, there would be an exception when callback() is executed. This is a weak spot in the API, because now the constructor code (which belongs to the API itself) needs to pass a callback argument to its own call of init . Although that constructor does not need to be "called back", it must provide a valid callback, and so it passes a dummy one:

callback => {}

Several comments about this:

• This is not a function that returns an empty object. It is a function that executes an empty statement block.

• The function takes an argument that is called callback . Probably the author thought this would help understand that this callback is a ... callback, but honestly I find it confusing to call a parameter of that function callback : that isn't a callback -- it is an unused parameter of the callback.