Hey folks, how do we want to handle dependencies in our DRY packages?

Solution 1: export dependencies

We could bundle with the dependencies and export it. This would mean only our package has to be imported and here the pg package is also available in using projects. However, I think this is a bad style, right? However, this would make sure that pg is compatible with the right version with our helpers.

Solution 2: only use the types

We could also add no runtime dependency but just add types (and the dependency if necessary for testing) as dev dependencies. This would keep the package smaller, but the client has to add here the pg dependency itself. This could lead to situations where we get out of sync with the pg version. However, I guess it would be cleaner?

@lunedis @mathiaszinnen @MBuchalik @jsone-studios Opinions?

There are only two hard things in Computer Science: cache invalidation and naming things.

I would propose to change the name of the exported PostgresRepository class. For me, the Repository part does imply that it has something to do with the Repository design pattern. But that's not the case, because the class does neither have domain nor data mapping knowledge. Instead, it is just a tiny wrapper around the pg library.

I would change the name to PostgresDatabase or PostgresClient. @georg-schwarz what do you think about that or do you have other name suggestions?