PG as runtime dependency or dev dependency?

[georg-schwarz]

PG as runtime dependency or dev dependency?

[sonallux]

Well, I think there are more options to consider, because npm has the concept of specifying dependencies, devDependencies and/or peerDependencies in package.json.

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.

Yes, I would consider this bad style. Another drawback with this approach is that every time a new version of pg is released, we must also release a new version of the library.

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?

Not specifying pg as dependency is also not an option because it can get easily out of sync. But that's way package.json has the dependencies, devDependencies and peerDependencies fields. There is a great explanation on StackOverflow about the differences. Unfortunately, it is a little bit outdated regarding the peerDependencies because their behaviour has changed in the recently released npm@7, which is going to be shipped starting with NodeJS 15. But as the concept of peerDependencies does not match our use case this does not matter really.

So I would add the pg dependency in the dependencies with the carat (aka hat) symbol ^8.3.0, so everything greater than a particular version in the same major range is included. Then the latest version matching the version range is always installed when using the library.

For the @types/pg dependency things get complicated, because it is only required if the user of the library is using typescript. So if we specify @types/pg in dependencies a user of the library only using JavaScript will unnecessarily download the @types/pg dependency. But if we specify @types/pg in devDependencies a user of the library using TypeScript will not get @types/pg automatically installed and must install on their own. As we are currently the only users of the library and we are always using TypeScipt I would add @types/pg also to the dependencies.

---

For all unfamiliar with the carat (aka hat) symbol or the tilde symbol before version (for example ^8.3.0 or ~1.2.3 or ^2 <2.2 || > 2.3), there is an npm semantic version calculator which displays nicely which version are matched by those ranges.

[georg-schwarz]

Actually, the peerDependencies might fit our use case because we kind of add a plug-in? Not in the traditional way, but we want to relate to a pg version that is pulled in from the parent project I guess.

What changes in npm@7 is the algorithm of how peer dependencies are isntalled. In my understanding, this is even better since it adds an auto-install if the parent project does not explicitly reference the dependency, but still detect unmatching versions if present.

Regarding the types, I am also quite unsure. I mean we already bundle with our own type files, so we could do this again here. However, if we use peer dependencies the parent project should include the types IMHO.

[sonallux]

Actually, the peerDependencies might fit our use case because we kind of add a plug-in?

Not really, as we are requiring pg in our code. And according to the npm documentation, that should not be done for peerDependencies...

Also, I think this library is more an abstraction or a wrapper around the pg library. With the library, the user only needs to provide a configuration and then he can execute SQL statements. The library is doing all the heavy lifting, like creating a database connection.

[georg-schwarz]

Allright, thanks @jsone-studios !