Proposal for offering first-class support to Kibana.

Requirements

• Avoid the creation of a wrapper
• Some properties and methods of the client should not be accessed by mistake
  • transport
  • connectionPool
  • serializer
  • close
  • child
  • extend
  • on
  • once
  • emit
• Simplified type definition (the work done in Export a kibana restricted type definition #1239 will merged here)
• Ship the kibana type definition with the client
• The chosen solution will be part of the testing suite of the client
• Support of jest mocks

Implementation

Currently, the idea is that the Kibana client will extend the base Client and hide the properties that should not be accessed by plugin users.
The main counterargument of this approach is that if Kibana core needs to access these methods, we'll need to re-expose them via symbols, for example:

const kClose = Symbol('kibana-client-close')
class KibanaClient extends Client {
  get [kClose] () {
    return super.close
  }
}

const client = new KibanaClient()
client[kClose]()

A different solution is to exclude the properties we don't want to be accessed with a builder function.

const client = new Client(opts)
function buildKibanaClient () {
  return {
    ...client,
    transport: {
      request: client.transport.request.bind(client.transport)
    },
    connectionPool: undefined,
    serializer: undefined,
    close () {
      throw new errors.ElasticsearchClientError('Cannot access close method')
    }
  }
}

const kclient = buildKibanaClient()

In my opinion, the first method is more elegant, as it uses idiomatic JavaScript to solve the issue, but will require you to use symbols for accessing "private" APIs. The second method feels hackier, as we'll need to bind the client in some places, but it removes the need to use Symbols at all.

@elastic/kibana-platform what do you think?