Skip to content

Developing Nibble

Developing Nibble

Working on Nibble itself, rather than on a site built with it.

This section is for working on Nibble itself. If you are building a site with Nibble, you want Building a theme instead — you should almost never need to change Nibble to build a site, and if you do, that is worth saying out loud in an issue.

The pages

Page What it covers
Architecture how a request becomes a page, the modules, and where code lives
Invariants the rules the codebase holds to, and the tests that enforce them
Tests and checks bin/ci and everything it runs
End-to-end tests the browser suite and the playground
Deployment Kamal, and what a container does before it serves
Releases cutting one, and what a site sees
Contributing sending a change back
Commands every nibble:* command in one place

Getting set up

git clone https://github.com/mah3uz/nibble.git
cd nibble
bin/setup
bin/dev

bin/setup installs dependencies and prepares the database. bin/dev starts the application, the asset build and server-side rendering together.

Before you push anything:

bin/ci

That is the same suite that guards a release: Ruby and JavaScript style, types, schema, security, both test suites, the asset build and a server-rendering smoke test. It takes well under a minute.

The shape of the thing in one paragraph

Rails 8 serves both the public site and the control panel through Inertia and Vue 3, rendered on the server. SQLite holds the content, the cache and the job queue — one file, no separate services. Content is schema-driven: YAML declares what exists, and entries are rows whose fields are validated against a blueprint. Uploads go to S3 behind a CDN. Deployment is Kamal onto a plain virtual machine.

Read Architecture for the detail, and Invariants for the handful of rules that are not negotiable.

Previous
Seams