DaloyJS Is in Beta (and Nothing Broke, on Purpose)
After a long public preview, DaloyJS enters beta. The funny part: the most important line in this changelog is that nothing changed. Here is what the beta means, how to install it, and what we need from you before the stable release.
DaloyJS just crossed a line I have been quietly nervous about for months. We tagged the beta. The framework that spent its whole life in public preview is now being tested as a stable foundation for production applications.
And here is the part that feels like a punchline: the single most important line in this changelog is that nothing changed. No new middleware. No new adapter. No clever helper I will write three blog posts about. If you were on the final preview release yesterday, the beta is the exact same code with a braver version label.
So why bother tagging it?
Because a stable API is a promise, and I finally felt okay making this one. During preview the deal was simple and a little rude: public APIs could still move. That is normal for a young framework. You move fast, you rename things, you apologize in the changelog. It is also exhausting for anyone trying to build something real.
The beta flips that deal. The public API is feature-complete and stable. From the stable release onward we follow SemVer like adults: minor releases do not introduce breaking changes, and deprecations get at least one minor cycle of warning before anything disappears. The beta is me saying I think we are ready, then handing it to you to prove me wrong before the stable release.
Wait, nothing changed, really?
Really. But that does not mean nothing happened. The work that earned a stable release happened across the entire public preview: the secure-by-default request path, the contract-first route that generates OpenAPI plus a typed client, the multi-runtime adapters, the supply-chain hardening, the SSRF guard, the auth and rate-limit and webhook pieces, all of it. Beta day is not when the features arrive. It is when I stop adding features and start defending the shape of what is already there.
Your existing app still looks like this, because of course it does:
How to get it
We published the beta to the latest tag on npm and to JSR, in lockstep across @daloyjs/core, create-daloy, and @daloyjs/daloy. So a plain install gets you the beta with no special incantation:
Quick aside, because I almost did the clever thing here. The instinct with a beta is to hide it behind a beta dist-tag so that a normal npm i keeps handing people the last stable release. That is the responsible move when you have users who did not ask to be guinea pigs. We do not have that problem yet. We have the opposite problem: zero users to surprise, and a lot of people to win over. Parking the beta in a corner where nobody trips over it would have been the cautious choice and also the useless one. So it goes to latest. Come trip over it.
What I actually want from you
A beta is not a victory lap, it is a request for evidence. The best possible outcome for the next few weeks is that someone builds a real thing on the beta and finds the rough edge I missed. File the bug. Tell me the API name that reads wrong. Show me the adapter that behaves differently than the docs claim. That is the entire point of shipping a beta instead of just tagging a stable release and praying.
If you want the full picture before you dive in, the case for using DaloyJS today covers the why, and Secure by Default covers the defenses you inherit on the very first route. Then go run pnpm create daloy@latest and report back.
One small, slightly emotional note to close on. Tagging a beta, even a boring one, is the part of a project where it stops being a thing I am tinkering with and starts being a thing other people are allowed to depend on. That is terrifying in the good way. Thanks for being early.
About the author: Filipino developer in Norway who has shipped enough 'small' version bumps at 2am to respect the boring ones.