Hey HN, I wrote this little library a while back. This may be a bit of a niche thing, since there hasn't been much prior art tackling this problem. Before making json-qs, I was using my fork of juri [1], but it valued compression too much for my taste and, IIRC, I had some issues with it (can't remember the specifics).
If anyone has any feedback on the design, I'd be interested in hearing it. Or if you have questions about design choices, I can answer them. Thanks for reading!
I used this initially in a browser extension I'm building. Ended up migrating to a JSX library instead, because jQuery turns into hard-to-reason-about code pretty quickly once you're past “simple app” territory (and I say this as someone who wrote my own jQuery-inspired library[1]). Right tool for the job, as they say.
The most common case is probably complex search queries. It's really nice not having to flatten your data just to get network level caching.
In my case, building an RPC library with REST semantics, it's important to me to not place any restrictions on how developers pass their data to the backend. So removing that arbitrary flattening requirement is a big win. The json-qs specification does it in a way that balances readability and compactness.
The home feed is a poor experience, IMO. Adding a tagline to each product would help me know if I want to learn more, without having to decide to click based on a logo and name alone. I think categories would also help me find what I'm interested in.
I'd love to get everyone's feedback on this library I made.
I've found it helps a lot when writing a library that takes advantage of compile-time code generation. In the future, I think it could be cool to try and integrate jumpgen with bundlers, like Vite or Rollup, so your file generator can be used as a bundler plugin. Currently, jumpgen “generators” only have a programmatic API, but jumpgen will have a CLI as well, if you think that could be useful. Mostly though, jumpgen is intended as a “white label” library that is contained by your own CLI, if you have one.
# Motivation
Code generation can be useful for many tasks. I'm using code generation in my own libraries, pg-nano[1] and alien-rpc (in development). In pg-nano, I'm generating TypeScript functions that mirror Postgres functions (aka UDFs). In alien-rpc, I'm generating runtime metadata for RPC-style API routing.
I could not find a library that simplifies the task of writing a code generator, so I made jumpgen.
# What It Does
It's designed to handle the burdens of implementing a “watch mode” for your generators. It also returns an event emitter, especially useful for logging. Your generator is free to work in relative paths, since jumpgen handles path resolution according to a user-provided root directory.
It tracks which files your generator has read into memory and which directories your generator has listed. When those files/directories are changed or have files added/removed, your generator will rerun automatically (if watch mode is enabled). This even works with globs!
I've also included a "dedent" helper function so you can indent any template literal without that excess indentation carrying over into the emitted files.
# Feedback Wanted
If this sounds interesting to you, I'd love to hear any comments or criticisms about the API, the readme, or whatever else. Thanks!
That's not entirely true. Tree-shaking algorithms could have a “noDynamicAccess” option that errors on such use (only viable for applications, not libraries). Alternatively, the algorithm could be integrated with the TypeScript compiler API to allow dynamic access in some cases (e.g. where the `anything` function in your example only returns a “string literal” constant type or a union thereof, instead of the `string` type).
It requires flow analysis, which is really hard to get right. I don't think there's a tree-shaking library that uses the TypeScript compiler API for static analysis purposes. Maybe because it would be slow?
edit: The creator of Terser is working on flow analysis for his new minifier, according to him[1].
I'd recommend TypeBox[1] as an alternative, which has a runtime “compiler” for generating optimized JS functions from the type objects. It also produces a JSON schema, which can be useful for generating API docs and API clients if needed.
It also has a companion library[2] for generating TypeBox validators from TypeScript definitions, which I'm currently using in an RPC library I'm working on.
I'd love to hear more about your experience with web discoverability, as I'm making a product that aims to help with that. Email me at alec.stanford.larson @ gmail
I don't know if much can be done about echo chambers. People seem to like their echo chambers. For those who are sick of such environments, I've designed another system (not yet part of the product I mentioned above) that I believe has the potential to breed a place of authenticity on the internet.
That's not supported yet, but it will involve removing the foreign key constraint from one table (by parsing and rewriting the CREATE statement before running it). Then after the referenced table has been created, add the FK constraint with an ALTER statement.
There's also the DEFERRABLE constraint setting[1] for one-to-one relationships (which can usually be avoided via a joint reference table). This pattern should already work in pg-nano.
I wouldn't compare the two directly, as they serve different preferences. I would say that using Postgres functions is more powerful, but that may not matter for your app, depending on its complexity and needs. Ultimately, I'm not concerned with persuading Prisma users to switch over just yet.
As far as migrations go, pg-nano is taking the same “schema diffing” approach that I assume Prisma does, where the active schema of your Postgres instance is compared to the desired schema (defined via SQL files in pg-nano's case) and a migration plan is generated from there. In the context of migrating a non-local Postgres instance, pg-nano still has some R&D to do.
You could use both side-by-side if you prefer query builders for certain tasks, but that means you'll be bundling two Postgres drivers in your application server, which could mean hitting the connection limit of your Postgres instance. Although, pg-nano has a way to limit number of parallel connections at the cost of reduced throughput.
> Seems like this tool could essentially pre-create the types for any raw Postgres SQL statement?
It's a syntax parser that produces an AST. So only information explicitly defined in the syntax is available. To infer input/output types for an arbitrary SQL command, you need introspection (the most fool-proof way being PQdescribePrepared[1]).
> Being able to use raw SQL and get query types "for free" would be amazing.
That's basically what pg-nano does, but you need to use Postgres functions, rather than "$1" or "?" placeholder templating. Of course, some people prefer co-locating their raw SQL inside their TypeScript files, in which case, pg-nano is not for them.
The main reason I didn't contribute my changes via PR is I wanted a package without "deparse" support, which adds considerably to the install size. I also didn't want pre-compiled binaries for every supported platform to be published to NPM, preferring a postinstall script that only downloads the necessary binary. I don't know how the walk function would be received by the original maintainers, as I didn't ask.
> do you think it's possible to use your libraries to get the return type of an arbitrary postgres query, even if it's dynamic?
This is one of 4 reasons why I'm building pg-nano [1] and honestly the main catalyst. The other 3 reasons are: I still want to call my Postgres functions from TypeScript in a safe manner; I want declarative schemas with generated migrations; and I want the ability to write compile-time plugins that can generate SQL or TypeScript through introspection.
It's not released yet, but give it a look :) (v0.1 is almost done)
If anyone has any feedback on the design, I'd be interested in hearing it. Or if you have questions about design choices, I can answer them. Thanks for reading!
[1]: https://github.com/scrollback/juri