Garn: a TypeScript frontend to Nix

The garnix team has been working on a CLI tool, garn. The basic idea is to use TypeScript, rather than Nix-the-language, for configuring projects. This gives you much better discoverability (LSP hovers tell you what functions/attributes are available, and what their documentation is), errors (usually you get type errors while editing, rather than tracebacks afterwards), and, for most newcomers, familiarity.

The tool also provides a much more streamlined command line interface than nix.

The full announcement is here: garnix | the nix CI. The website for garn is here: https://garn.io/, and the repo: GitHub - garnix-io/garn. It’s still the first (beta) release - feedback would be very welcome!

7 Likes

Can I write entire nixos config with Garn, or is it just limit to configuring projects?

1 Like

Not yet, or at least not easily. But we’ve been thinking of it. Create an issue in the repo so you can track progress on that front?

hard-to-find-documentation (which is moreover often outdated)

I mean let’s hope this tool doesn’t suffer the same fate? But in general many approaches exist (let’s not forget all the yaml based ways of configuring your project) and most of them are either thinly documented or entirely out of use.

For instance, this: https://doc.deno.land/https://garn.io/ts/v0.0.14/mod.ts/~/javascript.mkNpmProject

Does not really help me in any way.

I’d also say that the level of functionality seen in the tutorial is relatively trivially achieved also using a flake.nix but where things turn to shit is when you have to do something slightly more complicated or something breaks. For that I’m not super sure how helpful another layer of abstraction is.

That said, I’ll be the first to hate on nix the language and somebody will hopefully get something right at some point.

1 Like

Does not really help me in any way.

Thanks for the feedback. I agree that the docs here could be better; I’ll add some more documentation. And if there’s anything in particular you feel is missing there, let me know. (Though my claim was only that they’re easier to find, and not outdated; if you have LSP installed, you actually get all of this as you’re typing - a dot gives you the options, and the docs for them. And because the types in TypeScript are actually typechecked, they’re never wrong, unlike the ones in nix docs.)

I’d also say that the level of functionality seen in the tutorial is relatively trivially achieved also using a flake.nix …

Yes, I think the main question will be how this scales to complex projects, and there’s a lot of work to be done there. But I think it’s also helpful to consider the people for whom writing that flake.nix isn’t completely trivial, or isn’t trivial at all. I actually would find it hard, in the sense that I’d have to do quite a bit of googling and copy-pasting to remember what the helper functions are, and a few cycles of forgetting semi-colons in various places, etc.

1 Like

I haven’t looked very hard into it, but wouldn’t this make it harder for downstream users to consume said software? (i.e.: it wouldn’t be possible to simply add the flake in question as a flake input)

You can still! garn generates a flake.nix, so you just have to commit that. But if you’re using garn downstream as well, you have the option of importing the Typescript library directly too.

I’m not sure that’s going to help that much. What I think is problematic about Nix is that it’s conceptually muddled and unclear. Any abstraction on top that uses the same conceptual model will suffer the same problems.

I agree there. Let’s hope this one sticks.