Postgres.js version 3 deployment size increase from ~19kb to ~62kb

[DimiTech]

I'm using postgres.js with Serverless functions so space is a critical factor for me. (also I appreciate simplicity & minimalism in programming)

When moving from version 1.x.x to 3.x.x I noticed a considerable size increase (postgres.js used to add ~19kb, but now it adds ~62kb to Serverless functions, significantly more).

1. Is there a way to mitigate this size increase? (I'm not using TypeScript and I don't intend to use it ever again)
2. Is it a good idea to maybe keep using version 1.x.x. ? Will it be supported in the future?
3. Why did this size increase happen?

Thanks for this awesome library!

[porsager]

Yeah, this is because cjs and esm is included, but we could generate cjs on install instead of including a prebuild. That should about halve the size.

[DimiTech]

That would be great, thank you!

[porsager]

I'm curious if we could get rid of the Typescript types too? Is there a way for them to be fetched only if someones using typescript?

[RoboPhred]

The traditional alternative to bundling types with your project has been to submit them to DefinitelyTyped. This will require the user to install the types by hand (using npm i -D @types/), but is a pretty common occurrence across most projects. It will also mean you have to keep an external repo in sync with the project, if you go that route.

If file size is a big problem in your environment, something like tree shaking is probably in order. It involves another compile step, but the size savings using something like babel, rollup, or webpack (in nodejs mode) to trim away unused files from the project would gain you significant improvements to file size, even among projects that seem to be pretty minimal already.

[RoboPhred]

Just did a quick size comparison:

postgres node_modules folder: 185kb (19kb typescript, 65kb EJS, 65kb cjs)
postgres EJS ran through webpack targeting node: 36kb

It looks like using tooling to reduce the size is probably the best way to go here, especially as all npm modules tend not to be focused on that metric and all have gains to be made when processed.

That said, are you using some form of tree shaking that isn't configured properly? The root node_modules folder is 185kb, the 64kb you listed seems to be much closer to the size of just one of the source folders. This seems to indicate you already are pulling out just the cjs or esm package you need, so the cjs/esm duplication isn't the issue.

In any case, the typescript typings shouldn't be causing any trouble at all for you, since they are in a different folder and not included in either of the cjs or esm folders. Cutting them out of the project would just save a paltry 19kb on npm install for no real benefit.

Can you give more information on how you are bundling your function to send it to the cloud? There should be a way to save more space here, but from the look of things the extra space used isn't due to the library's overall structure.

@porsager
I wouldn't recommend compiling the code fresh on install. Since it's still creating the files on install, you end up with exactly as many files / space in the node_modules folder. In addition, you now have to carry whatever toolchain you are using to build, so you bloat node_modules even more with a compiler that is never going to be used in production. That's not to mention all the trouble you can get into as the toolchain updates and you end up with different installs having slightly different code due to quirks in the compilation process.

[porsager]

Yeah, thinking some more about it, I don't think it makes sense to change anything on the Postgres.js end, this can be solved with eg ncc in user projects, which would get you to ~35kb.

[porsager]

Just converted this to a discussion instead since I think there's more to talk about and best practices to be shared.

Which service are you using @DusanDimitric, and I'm very curious, in actual numbers, what does the 19kb vs 62kb difference mean in practice? Is it deployment or longer cold starts, or where do you feel the pain?

I also forgot to answer your points, so here goes :P

1. Is there a way to mitigate this size increase? (I'm not using TypeScript and I don't intend to use it ever again)

I think it can be mitigated outside Postgres.js since it appears eg. esm standalone should only be ~35kb. And wrt. Typescript 🎉

2. Is it a good idea to maybe keep using version 1.x.x. ? Will it be supported in the future?

No, only if there is some severe issue, I'll of course look into fixing that, but I honestly don't see any reason to stay on v1 - there is more robust and performant connection handling in v3 even if you don't need any of the new features.

3. Why did this size increase happen?

I just checked and the size increase from v1 (22kb) to v3 (35kb), if we ignore the double esm + cjs issue, matches pretty well with the increase from adding realtime subscription, nested fragments, and the other new features.