Publishing to Dalea Community

Once a template is stable in your workspace, you can publish it as a package on dalea.market so other teams (in your org or in the wider community) can install it.

Everything published through the app is packaged as a bundle: one or more workspace items shipped together, with the references between them rewired when someone imports them. A bundle can carry six kinds of member:

The registry also knows the standalone template, block and environment package types, but those are legacy listings. If you pick a package id that already exists as one, the publish page tells you and suggests <id>-bundle.

Scopes — your namespace on dalea.market

Every package on dalea.market lives under a scope, written @scope/name. Scopes are like npm namespaces:

Personal scope (@your-handle)

Your own dalea.market handle. Only you can publish under it. Useful for personal templates and experiments.

Organisation scope (@your-org)

Registered automatically the first time any member of the org signs in to Dalea, so the org page exists before its first publish. The org slug is unique on dalea.market.

Org scopes are the right choice for shared institutional templates (your IACUC template, your standard ELISA SOP, your cell-line registration form). Personal scopes are right for individual contributions and experiments.

Permissions

There is no org-side publish permission to grant. Every member of the organisation gets publish rights on the org scope automatically, the first time they use Dalea: whoever registers the scope first is recorded as its owner and administers it on dalea.market, and everyone after that joins as a publisher.

To publish under a personal scope you need only your own account.

The publish flow

Publishing is a hand-off: you assemble and sign the package in Dalea, then finish it on dalea.market.

1. Open the Templates page and pick your template

   Its menu carries Publish to Community, or Update in Community if it is already listed.

2. Assemble the package

   The dialog seeds itself with your template and crawls what it references. Include any environment, saved query, block template or document that should ship with it, then fill in the package name, a short description and a markdown README (the README seeds the listing page, and you can polish it there afterwards).

3. Choose 'Publish on dalea.market'

   Dalea packages and signs the content, stages it on dalea.market and sends you there. The other destination, Download file, writes a .daleapkg you can hand to another workspace instead.

4. Set the coordinates on dalea.market
   • Publish as: the scope, your personal handle, or any org scope you belong to.
   • Package id: kebab-case, unique within the scope (iacuc-submission-acme).
   • Version: semver. Bump the patch for fixes, the minor for non-breaking additions, the major for changes that break documents already using the package. It prefills the next patch when the package exists.
   • Changelog: optional, markdown, frozen with the version.
5. Publish

   The registry verifies every content hash, countersigns and lists the version. A declarative package is installable immediately; a package containing addon code waits for moderator review.

6. Polish the listing

   The confirmation page opens the listing editor: display name, category, short description, tags, preview image and the full README. Those live on the listing, not on the version, so you can fix them any time.

There is no license picker and no homepage or repository field in the publish flow. Every package's license reads MIT unless it is set through the registry API.

After publishing

Each published version is immutable. To "edit" a package you publish a new version (1.0.1, 1.1.0, 2.0.0…). Old versions stay listed and remain installable until you yank them.

Maintenance you'll do over time:

• Updates: publish new versions as your template evolves. Update the changelog so consumers know what changed.
• Reviews and discussions: community members can leave 1–5 star reviews and start discussions on your package page. Respond promptly; high-quality packages have engaged maintainers.
• Stars: track which versions are popular. Useful signal for what to invest in.
• Unpublish: the listing editor's danger zone hides the package from browse and import. Publishing a new version re-lists it.
• Yank: pull a specific version if it has a serious bug. The version stays in history, shown as yanked with your reason, but it no longer downloads and latest moves off it.
• Deprecation: a package can be flagged deprecated with a message, which drops it out of search and the featured lists. It is a registry API flag; there is no button for it.

A realistic example

Your institution wants every research group to use the same IACUC template:

Publish as:    @acme
Package id:    iacuc-submission-mouse
Version:       1.0.0
Changelog:     First institutional release.

On the listing afterwards:
Display name:  IACUC submission, mouse studies (Acme institutional)
Tags:          iacuc, protocol, in-vivo, mouse, regulatory
Description:   Acme's institutional IACUC submission template for mouse
               studies. Pre-filled with our reviewer language; structure
               and default text are locked. Editable form fields cover
               study justification, animal counts, route-of-administration.

Publishing this once means every new programme inside Acme starts the same way. When the institutional language changes, you publish v2, and every team that imported it sees update available on Community → Installed.

Tips

What's next