Devlog: vibe coding myself some nix

Hello, my name is Morj, I’ve drank a cherry vine, a passionfruit beer, and half a bottle of soju. Somewhere in the middle I thought “holy shit, I’ve been procrastinating on that erlang project for such a long time, I need to move it along”. And so I am here, for you, my only reader.

So, here’s my thinking. I’ve written pokesz, and I’ve been using it heavily, despite the fact that JS sucks and I wanted to rewrite it in erlang or one of erlang’s friends or relatives. So, if I’m already using it, I need to write a proper nixos module for it, instead of using a tmux trick like I have been for the last two months. What tmux trick? I have my nginx set to make port 31337 available at https://random.test.morj.men, so I’ve been running deno run inside a shell and tmux detach-ing it. So the goal for today is have https://pokesz.morj.men be available as the pokesz server. For that, I need to write a nixos module that runs a deno program. Sounds easy? Sounds. It sounds like that because my rational part of the brain forgot that I drank some amount of spirits and am somewhat uncapacitated. Then I remembered: AI is going to replace us all, or so they say, so I should try outsourcing my thinking to it.

Here it goes:

I want to package a deno http server with nix. It doesn’t have a build step, in derivation I only need to copy the files to the target location. I also have a launch script in bash that runs deno with the right flags. Please write the derivation for me

Guess from 1 to 10 how bad was the response it gave me.

The answer: ehh, somewhat good? It was valid nix syntax, but with missing buildInputs and using some bad practices, like stdenv instead of stdenvNoCcc, and cp+chmod instead of install. But, mm, mostly it was fine. It even gave me a good recommendation on how to write the shell script. Which I personally was going to ignore (fuck around) and see (find out) if it works or not, but when the code is right here, why not copy-paste it, right.

So then, vibe-coding works! At least depending on your definition of working. I did have to edit the code it gave me, but I kept 30% of the lines and 90% of the structure. Personally, I find it a success. Nix docs are garbage, so having someone write a derivation for me, and then explain the parts of it, it’s convenient.

Deno is a piece of shit actually

My thinking with using deno instead of npm+node+whatever is the tool of the day, is that it would be better for stability purposes. Remember, my whole thinking was that having typescript and having NPM dependencies would tie me down to JS insfrastructure: instead of caring about code, I would care how to fucking run it in the year we’re in. Well guess what: the year is 2025 and I get hit with the following:

error: Unsupported lockfile version '4'. Try upgrading Deno or recreating the lockfile.

I’M SO FUCKING ANNOYED RIGHT NOW.

Not even a year has passed, not even half a year has passed, and I already can’t run my code. And for what? It’s not that something broke; if I downgrade deno everything works perfectly; I know that because my server still runs old deno without problems. Why the FUCK has the javascript infrastructure not figured out how to do non-breaking upgrades? Rust could do it since version 1.0, and maybe even before for some time. You already know the lockfile version! You already have the code how to handle it, the only thing you have to do is not be dicks about it and not remove it from the distribution that people use.

God damn it. And what’s even worse, is that this error message doesn’t tell me what to do. How the fuck do I upgrade my lockfile? I know I can delete node_modules, the classic solution, but then the version changes, and I don’t necessarily want that.

God damn it, let’s think about it while finishing the second bottle of soju..

Here’s what I thought: I can delete the lockfile, then recreate it, and then copy the hashes from the old one. And so I did. And so it worked. Kind of a dull conclusion actually. So let’s finish with a diff:

{
-  "version": "4",
-  "specifiers": {
-    "npm:ws@*": "8.18.0",
-    "npm:ws@^8.17.1": "8.18.0"
-  },
-  "npm": {
-    "ws@8.18.0": {
-      "integrity": "sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw=="
+  "version": "3",
+  "packages": {
+    "specifiers": {
+      "npm:ws": "npm:ws@8.18.0"
+    },
+    "npm": {
+      "ws@8.18.0": {
+        "integrity": "sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==",
+        "dependencies": {}
+      }
     }
   },
+  "remote": {},
   "workspace": {
     "packageJson": {
       "dependencies": [

And the final question is: WHY THE FUCK DID I even have to upgrade the lockfile? Nothing’s нахуй changed! It’s the same fields in slightly different spaces. Oh my god, I hate js infrastructure so much.

Ugh it actually works

I don’t remember how I got here, but I polished the nixos module and the derivation to the state where they actually work. So the lesson here is that it doesn’t require much thought to make nix work. Only luck.

I run nixos-rebuild switch, and I have the deno thingy working. I’m really eepy right now, so this is my clue to do like a tree and go. I’ll issue the https certificate and rewrite the nginx config tomorrow. Thanks for being with me. If there’s someone actually reading this, please write an email to mailto:blog@morj.men. It was fun just writin what came to my mind here, so maybe I’ll do it again, or maybe not. Ну точнее как то что пришло на ум, parce que ce qui est venu était en tous les trois langues, peut être encore plus. В конце концов мы не можем быть целиком собой, то что видят другие c’est toujours qqc de rédigé de nos vrais pensées. Alors bon, je m’apppele Morj et vous vous êtes fait maurgé(e)s.

The morning after

Ha, not so fast, yesterday’s me. Nix shouldn’t have allowed me to do what I did, because what happens when I launch the server is that it first downloads the npm dependency. I can fix it by removing write permissions from the running directory locally, which I now did. And by “fix” I mean make it so that the server doesn’t start, which might look like breaking it even more.

So how do I actually fix then? Obviously by vendoring? Obviously not, because npm packages in deno have a different semantic: for example, in my code I can’t use require, but the packge does it. So simply copying it and trying to import by hand will tell me to go fuck myself.

So here’s the current idea: I throw away everything I made yesterday, continue running the deno service in tmux dirtily, and only move it to it’s own domain. Sounds good? No it doesn’t, so hopefully it will make me started on the erlang version sooner.

So what did we learn? That you make better decisions when you’re sober. Goodbye.