Extending Nibble

Nibble has no plugin API yet. What it has instead is a set of seams: places a site can add its own behaviour where Nibble will keep finding it, so an upgrade never conflicts with what you added.

That distinction matters more than it sounds. Editing one of Nibble’s files works today and costs you an argument with git at every release. Using a seam costs nothing, ever.

Seam	Use it for
site/initializers/*.rb	your own Ruby, loaded after Rails’ initializers
Load hooks :nibble_entry, :nibble_term, :nibble_asset	adding behaviour to a record without reopening its class
Events	reacting after content changes, without patching what changed it
site/pages/<same path as ours>.vue	replacing one control panel screen
site/slots/{Logo,SidebarExtra,Scripts}.vue	replacing part of the control panel’s chrome
Gemfile.local	gems of your own
Webhooks	reacting from another application entirely

Seams covers each with an example.

Before you reach for one

Most things people want to add are already a schema change. A new kind of content is a collection; a new field is a line in a blueprint; a new block on a page is a set in a replicator and a .vue file. None of those needs a seam, and all of them are easier to live with.

Reach for a seam when you need behaviour — something to happen when content changes, a screen to work differently, an integration with a system of your own.

What does not exist yet

A plugin API: something installable that registers fieldtypes, screens and widgets together, with its own versioning. bin/rails nibble:generate:plugin refuses today and says why.

The fieldtype contract and the form handler seam already in the code are the likely shape of it when it arrives. If you are building something that wants it, that is worth saying in an issue — the shape should come from a real case rather than a guess.