Authentication screens, published into your project.
go run github.com/arandu-io/ui@latest authEighteen views, written in kyse: thirteen screens — the layout, dashboard,
welcome page, six base authentication screens and four two-factor screens — the
sign-in form as a fragment of its own, and both parts, HTML and plain text, of
the two messages the flow sends. Alongside them land ten plain Go files: five
authentication controller files, render.go, page.go, two mailables and
HomeController.go. Twenty-eight files in all, and they are yours from the
moment they land: edit them, delete them, rewrite them.
The fragment is under resources/views/partials/, and the directory is what
makes it one: a file there draws its own markup and no layout around it, so it
can be swapped into a page that is already on screen. A rejected sign-in is
answered with it, and with the whole screen when htmx is not running. Everything
else under resources/views/ extends the layout, and a test refuses a file that
is in the wrong one of the two.
Run it again to take a fix from a newer version: what you wrote inside a
arandu:begin custom block is carried over, and the command says so per file.
--views leaves the flow you edited alone — the five authentication controller
files and the two mailables — and refreshes twenty-one files: the eighteen
views plus page.go, render.go and HomeController, which they do not compile
without.
Nothing is added to your go.mod. go run <module>@latest runs a published
module without touching the caller's dependency graph, so there is no package to
install and none to remove afterwards. That is what makes this a package instead
of a subcommand: in Go the usual way to consume a repository is import, and
what you import you cannot edit — and editing the sign-in screen is the first
thing anyone does.
Five files are replaced without --force: the layout, page.go, home,
welcome and HomeController. A page renders with the type of its layout, so
the layout and everything that extends it are one unit; publishing a new layout
beside the old pages leaves a project that builds and fails to render.
The stack is HTMX and Tailwind v4, with the CSS compiled by a single pinned
binary. No Node, no bundler, no lockfile — and no client framework: the layout
this kit publishes loads htmx, ui.js, the component script and the theme
switch, and none of them reads an expression out of an attribute. It could not.
The policy is script-src 'self' with no unsafe-eval.
So state lives on the server, and the answer to a request is what says so. A
handler decides and writes markup that is already correct, which leaves nothing
in the browser to keep in step. What dies with the tab — a menu that is open, a
row that is selected — is ui.js's, kept in the ARIA the markup already carries,
so the DOM holds the only copy. The gates that hold the kit to it read the
published bytes: a fragment may not carry a layout, a handler answering one may
fill only what it draws, nothing the layout draws is drawn inside a swap as well,
and no view keeps a value in an x- attribute.
The API reference is generated from the doc comments and lives on pkg.go.dev. Every exported symbol carries one, and that is deliberate: it is the documentation that cannot drift from the code, because it sits in the same file.
The CLI documents itself. aru help lists every command, and each one explains
what it writes and what to do with it. aru doctor explains what it found and
what breaks, not which rule was violated.
A guide and a website do not exist yet, and that is a decision rather than a gap: a guide written against an API that still moves is work done twice, and the second time is worse — there is wrong documentation published. The site is the next phase, and it will be an Arandu application.
See CONTRIBUTING.md. Before opening a pull request, the three commands at the top of that file have to pass, and CI runs exactly them.
Please review our security policy on how to report a vulnerability. Never open a public issue for one.
Open-sourced software licensed under the MIT license.