A fix release. One fix comes straight out of v0.6.4 and needs a minute of your time. The rest are older bugs, found while chasing it.

The .gitignore

Moving lib/ into var/ had a side effect I missed.

Projects created since late August ignore /var/ as a whole. That was fine while var/ held only the Vite cache. Now it holds var/lib/ too, and git never reads a .gitignore inside an ignored folder.

So the derivation cache, the cache.json files var/lib/.gitignore is there to keep, quietly stopped being committed. Every fresh clone and every CI run paid for a full rebuild.

New projects get the right rule out of the box now. For an existing project, replace the /var/ line in your root .gitignore with these two:

.gitignore

/var/*
!/var/lib/

Everything else in var/ stays ignored, and var/lib/ follows its own rules again. That's the minute.

Static files with spaces in their names

dist/run.js looked up files by the URL as it arrived, still percent-encoded. So public/My Photo.png was requested as /My%20Photo.png, never found, and answered with index.html and a 200.

Paths are decoded now, so files with spaces or non-ASCII names are served as they should be.

And a missing file under assets/ is a 404 now, not index.html. That's the hashed chunk a browser still asks for after a deploy, and it's better reported as missing than parsed as HTML.

Aliases answer the same everywhere

The dev server, dist/run.js and the SSR server each had their own copy of the rules that decide which folder answers a URL. Three copies, and in one case they disagreed. In a client-rendered folder, an alias that sits under the folder's own frontend base, say /shop/feed.xml with pages at /shop and the API at /api, reached the backend in dev and got index.html in production.

The rules live in one place now, and all three servers use it. And the rule itself is written down: an alias names one exact URL, so it wins over any base, the folder's own or another folder's. Details ›

One behavior change comes with it. An alias under another folder's longer base used to be answered by that folder. Now the alias wins there too.

Deleted routes clean up after themselves

Deleting an API route left its derived files behind in var/lib/: types, schemas, the fetch client, and the derivation cache. With the cache committed again, those would have stayed in git too.

Now the dev server removes them when the route goes away. Nested routes keep theirs, and folders left empty are removed.

This happens while the dev server is running. Routes deleted while it is off, say on a branch switch, still leave their files behind. Delete var/lib/ in that case, and the next start rebuilds it.