Publishing & installing addons
Bundle, review, publish to the community, and install into another workspace.
Once an addon works in your workspace, you can share it with the wider community by publishing it to dalea.market — the same marketplace that carries templates and packages. Another workspace installs it in one click, re-maps it to their own data, and runs it.
Publishing goes through a build-and-review gate, because an addon is executable code that will run in someone else's workspace. This page covers what ships, how it's reviewed, and how installation works on the other side.
Every addon ships as a bundle
An addon rarely stands alone — it references a table, an environment, a
document. So every addon publish is a bundle: the addon itself is always a
member, and each entity it references can ride along too. The derivation is
automatic from the addon's externalEntities:
- A data table
- Ships its parent environment (bundles carry whole environments; the table id is rewired on import). Several tables from one environment collapse to a single member.
- A data environment
- Ships that environment.
- A template or document
- Ships that document/block template or document.
- Anything else, or unmapped
- Can't ride the bundle — it travels by description, and the installer re-maps it to their own entity.
In the publish dialog each derivable reference is a checkbox — include it to
seed the installer with a working copy, or exclude it so they wire the addon to
their existing data. Either way the description you wrote on each external
entity is what guides their mapping, so make it an instruction.
Publishing
- Finalise and enable the addon/addons/{id}
All external entities mapped, a green build, and the addon enabled. You can't publish a disabled or failing addon.
- Click Publish to dalea.market
Dalea derives the bundle members from the addon's references and opens the publish dialog.
- Choose the bundle members
Include or exclude each referenced environment, template or document.
- Set scope, metadata and version
Pick a personal (
@your-handle) or org (@your-org) scope, a package name and description, tags, and a license — the same metadata as any package. Use semantic versioning; each published version is immutable. - Publish
The registry builds and scans the addon, then registers the version. It is not publicly installable until it passes review (below).
The metadata, scopes and versioning work exactly as they do for templates — see Publishing to dalea.market for the full walk-through of names, licenses and semver.
The review gate
Because the artifact is runnable code, the marketplace doesn't take the publisher's word for it. On publish, the registry delegates a full build of the source in publish mode to the addon build service, which statically scans it and lands the version in one of two states:
- pending
- A clean build. Awaiting an admin's approval.
- in_review
- The scan raised a flag —
eval/new Function, an attempt to construct network egress, a mismatch between declared scopes and code, or a hardcoded id. Goes to the manual review queue.
Neither state is publicly installable until an admin approves it. The source set — not a pre-built blob — is what reviewers read and what the registry hash-anchors and signs, so what's reviewed is byte-for-byte what installs.
A raw workspace id baked into published source can't be re-mapped and would
point at data the installer can't see. The build rejects UUID literals outright
— always route workspace references through
process.ext.
Installing
Installing an addon from the marketplace creates a linked addon in your workspace: pinned to the published version and read-only — its scripts and manifest can't be edited in place. Two things you'll do right after:
- Re-map the external entities. Anything that travelled by description (or
wasn't included) starts
UNMAPPED; point each one at your own table, environment or document in the mapping dialog, then build. - Review and enable. As with any addon you didn't author, a person approves the scopes it requests before it can run.
When the publisher ships a new version you can pull it — the update re-checks that the version is approved and re-validates the scopes it asks for.
Detaching
To modify a linked addon, detach it. That converts it from a read-only marketplace link into a fully editable local addon.
Once detached, an addon is a local copy and can't be re-linked to its marketplace source — you won't get its future updates automatically. Detach when you genuinely need to fork the behaviour, not for a one-line tweak you could contribute upstream instead.