Release prep

[mustafaiman]

This is mostly exposing both HazelcastClient and Config classes to users. Before this PR, we managed to use Config class in tests because we require it directly from lib folder by specifying the folder name. This is not desirable for end users.
With this PR users will be able to import

• HazelcastClient as require('hazelcast-nodejs-client).Client
• Config as require('hazelcast-nodejs-client').Config

This PR also adds "typings": "lib/index.d.ts" line to tsconfig.json. Typescript users will be able to use static type checking.

Adds "target": "es5" to tsconfig. Default was es3. Node.js fully supports es5. There is no compatibility issues with it.

[GhostInAMachine]

Has conflicts

[GhostInAMachine]

What exactly does using "es6-promise" achieve? It's just a watered down version of RSVP

[mustafaiman]

@GhostInAMachine I am trying to decouple the Promise API from actual implementation. I thought of es6-promise as an API declaration. I may be wrong. Do you know how to instruct tsc compiler of users to use type definitions of ES6 Promises without depending on any specific implementation?

[GhostInAMachine]

I'm not sure if ES6 promises will be an API to be implemented by third party solutions (like https://promisesaplus.com) or a thing to be included in ES6-compliant runtimes. I think it is the second.

https://tc39.github.io/ecma262/#sec-promise-objects

For the time being it is better not to concern ourselves too much with it.

[mustafaiman]

If we provide API correctly, users are not restricted to use Q for their promises. I think this is a must because people will not want to introduce another promise library to their environment if they use Bluebird for example.

[GhostInAMachine]

Good point, but the latest commit in this PR does not remove dependencies to Q.

Let's make it a goal for the next milestone.

[mustafaiman]

It removes all dependencies to Q except one piece of API (Invocation). I am trying to remove it, too.

[GhostInAMachine]

import * as Q from 'q';

How does this remove a dependency from Q?

[mustafaiman]

We internally depend on Q for our promises. What I am doing is removing references to Q from our own public API. We should not expose anything specific to Q either in arguments list of our own public methods or return value of them.

[GhostInAMachine]

Either way, I can't accept this PR with es6-promise, this is a rather weird solution to the problem.

[mustafaiman]

I just bumped into microsoft/TypeScript#4168 (comment) . I do not like the solution either but I guess this is a common one.

[GhostInAMachine]

Then perhaps we need to think of a better one.

[GhostInAMachine]

Please remove last commit for this PR, let's discuss this problem more thoroughly. This holds back the rest of commits in this PR.

[mustafaiman]

I removed the last commit but added a new one. New one changes module imports from deprecated import Q = require('q') syntax to import * as Q from 'q' syntax.