monorepo

@charmander @bendrucker @sehrope @vitaly-t @abenhamdine

Sorry for the pings, but y’all are probably the most active contributors & I wanted to get your opinions on something I’ve been thinking about for a while…

Long, long ago pg was one big repo with lots of functionality in it (native bindings, the pool, some connection string parsing, type parsing). Then later as the trend of smaller modules became a thing I spun some stuff out into their own repos. I then built some extensions that are pretty dependent on the version of pg. So now we have this:

https://github.com/brianc/node-postgres https://github.com/brianc/node-postgres-docs https://github.com/brianc/node-pg-native https://github.com/brianc/node-libpq https://github.com/brianc/node-pg-types https://github.com/brianc/node-pg-pool https://github.com/brianc/node-pg-query-stream https://github.com/brianc/node-pg-cursor

This ends up making it a lot harder for me to track issues across all the issues and coordinate semver changes between the various dependencies. Particularly w/ things like pool error handling changing. How would y’all feel about combining some of these into a single repo and managing all the packages with lerna? I don’t need to combine them all - particularly pg-types & its friends are more managed by @bendrucker (I’m happy to though if you want).

At the least I’d like to bring in the docs, pool, query stream, and cursor into this repo as often times working on the pool makes me want to change behaviors in the client or vise-versa. And query-stream and cursor are really dependent on the behavior of errors and types and so on from the core lib. I might leave the native bindings external…not sure about that yet…those really could use a full blown new maintainer as working with C/C++ is so difficult for me…I don’t ever do it at my day job anymore and so I get lost easier. Anyways…what do you think? As a first step I was thinking of collpasing pg-pool pg pg-query-stream and pg-cursor (and the docs) into this repo and managing it all w/ lerna. That should make it easier to coordinate an 8.0 release of this library as well as everything can be major versioned in lockstep. I’d like to think it’d make issue management both a bit easier for me (one place for issues instead of 10) and hopefully for users as well as it’s just 1 repo to open an issue on instead of trying to find where it goes.

Any strong feelings either direction on this?

[vitaly-t]

If this should happen, you should definitely go for TypeScript. The conversion would be quite simple, and make it much easier to maintain.

I’ve done it myself a number of times, taking small independent modules and converting them into TypeScript. It simplifies the integration as well.

But the Native Binding should remain external, because bringing in a gyp dependency will cause trouble to many novice developers.

[bendrucker]

Seems worthwhile to bring the “client” modules that deal with networking, querying, etc. into a monorepo if they’re tightly coupled. Dubious on TypeScript. Publishing transpiled code to npm introduces issues tracing lines back to the source code. To date I’ve asked anyone looking to contribute types to do so via a .d.ts file and provide some tests that do basic type validation via https://github.com/SamVerschueren/tsd.

Most of the type packages are not very tightly coupled. 👍 to deferring that for now. Might make sense to be its own separate monorepo, but I’d like to see how this goes in core before committing a bunch of time to migrations.

Probably also worth adopting scoping, i.e. @postgres/*. That username is abandoned so if you’d like to do that I can ask npm about it and create an org.