thanks for sharing! author of pgpm here, we are super excited about pushing e2e and integration testing in the postgres community, a big part of the modular postgres workflows in addition to the modules/packages.

We'll be continuing to improve and work on the developer experience for postgres and building applications, thanks again!

thank you! let us know if you need help setting it up!

appreciate it! let us know if you and your team have any feedback, cheers!!!

thank you! much appreciated ;) hope it helps you guys ship secure supabase projects!

thank you! Appreciate that.

Always want to make the glide path and ensure folks can run the software replicably on their machines!

happy to help if you run into any issues :)

ES modules are cancer. I'm fine w the syntax — in fact, I love the syntax.

But if you use "module: true" in your package.json, you are splitting the npm ecosystem into two groups, and it's not moving us forward.

and fwiw, my opinion comes from attempting to upgrade packages that I've depended on that all of a sudden add the module: true, which essentially requires that ALL packages must upgrade — which is 99% of the time not possible because all the other deps are usually CJS.

this is also similar to the non-incremental way TS rolled out in the early days, also causing knee-jerk reactions to TypeScript. However over time, devs found ways to incrementally type JS to TS, and so we've all mostly evolved by now.

If ESM could do similar, allowing for incremental evolution, then it would solve all of the problems. I don't see why cjs and esm cannot co-exist

My journey to upgrade pgsql-parser to TypeScript led to an exciting discovery in the pganalyze/libpg_query repository: protobuf files defining PostgreSQL's AST. This discovery inspired me to create a proto-to-TypeScript transpiler, streamlining the process of typing the pgsql-parser and unlocking other cool new features :)

The transpiler not only allowed me to add typing for pgsql-parser but also spawned a suite of TypeScript utilities that are invaluable for PostgreSQL development.

Explore the tools:

pg-proto-parser: https://github.com/launchql/pg-proto-parser pgsql-parser: https://github.com/launchql/pgsql-parser

Additionally, we now have new utilities generated by the proto parser, make sure to checkout the @pgsql/utils! That has some cool features in it:

@pgsql/enums: https://github.com/launchql/pgsql-parser/tree/main/packages/... @pgsql/types: https://github.com/launchql/pgsql-parser/tree/main/packages/... @pgsql/utils: https://github.com/launchql/pgsql-parser/tree/main/packages/...

Hope you enjoy! Please let me know anything you'd like to see!

An article about ASTs in postgres, featuring a postgres AST deparser written in pure pgsql

HI all! I wanted to share a useful tool that I built during the pandemic. One of my deepest projects I’ve created in postgres, and I’m excited to share it with the community and get ideas and feedback.

I do a lot of functional programming and needed dynamic SQL. My personal belief is that ORMs are the wrong interface to creating migrations, and I prefer a pg native, functional approach. This library was actually one of the base extensions of a larger set, that I used this to create higher level structures for creating migrations. So while this is “low-level” you can definitely create stored procedures that do make higher-level if you wish.

I hope some of you find this useful with your projects!

postgres-ast-deparser A pure plpgsql AST toolkit and deparser for PostgreSQL, which can be used to create ASTs and deparse them back into strings in native Postgres. https://github.com/pyramation/postgres-ast-deparser

wow, session replays looks pretty slick!