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 imports it with the package page's Import Bundle button, 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 saved query
- Ships as its own member.
- A template or document
- Ships that document/block template or document.
- An attached file
- Travels inside the package automatically; you do not include it yourself.
- Anything else it references
- Records, result batches, naming schemes, import mappings, projects, folders, document blocks and inventory entities are not packable. They travel by description, and the installer re-maps the reference to their own entity.
In the publish dialog each derivable reference gets an Include button: include
it to seed the installer with a working copy, or leave it out 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 the addon/addons/{id}
All external entities mapped and a green build. A failing build is rejected by the registry. Enablement is a per-workspace runtime gate rather than a publish gate, but enable it and run it once anyway: it is the only way to know the thing works.
- Choose Publish from the addon's menu
The item reads Publish, or Publish update once the addon is already on dalea.market. Dalea derives the bundle members from the addon's references and opens the packaging dialog.
- Choose the bundle members, name and README
Include each referenced environment, saved query, template or document you want to ship, and fill in the package name, short description and markdown README.
- Pick 'Publish on dalea.market' as the destination
Dalea packages and signs the content, then stages it on dalea.market and hands you over. The other destination, Download file, writes a
.daleapkginstead. - Finish the publish on dalea.market
There you set the scope (
@your-handleor@your-org), the package id, the semver version and an optional changelog, then publish. Each published version is immutable. The registry builds and scans the addon before registering the version, and it is not publicly installable until it passes review (below).
Scopes and versioning work exactly as they do for templates. See Publishing to dalea.market for the full walk-through of scopes, package ids 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, adalea.<domain>call with no matching scope declared, an externalhttp(s)://URL in a load position, or hardcoded chrome colours that ignore the workspace theme. 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
Importing an addon from dalea.market creates a linked addon in your workspace: pinned to the published version and read-only, so 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, click Make editable on its linked banner. That detaches it from the marketplace source and converts it 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.