This document is the guidelines for integrating pg-promise into reusable libraries.

The standard way is by adding pg-promise as a dependency in your package.json.

advantages:

• isolated use of promise libraries
• coding only for the referenced version of pg-promise
• providing your own Initialization Options

disadvantages:

• requires separate database connection parameters
• requires creation of a separate instance of the Database object

If the client module creates its own Database object from the same connection parameters, it will result in a duplicate Database object warning, as explained in the Database API.

You can accept db - Database object as a parameter, to use it directly. And you can access all pg-promise features via property db.$config.

advantages:

• consistent use of the Initialization Options, as configured by the client
• no dependencies: reusing pg-promise and the promise library as configured by the client
• no duplicate Database objects, optimal use of the connection and event listeners

disadvantages:

• cannot set your own Initialization Options, and you can break the client's code, if you try
• can only use the basic promise methods as exposed via db.$config.promise

You can support pg-promise via dependencies (for the default), and via db parameter as an option.

This is the recommended approach, to let your library meet demands of both client types:

• clients that use pg-promise internally will be able to pass in db as a parameter
• clients that do use pg-promise internally will rely on your library's defaults