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

  1. 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.

  2. 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.

  3. 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.

  4. 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 .daleapkg instead.

  5. Finish the publish on dalea.market

    There you set the scope (@your-handle or @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, a dalea.<domain> call with no matching scope declared, an external http(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.

Hardcoded ids are always wrong

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.

Detaching is one-way

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.

What's next