Using the Registry

This guide covers day-to-day registry usage from the CLI and web interface.

Configuring registries

Registries are defined in your project’s .duumbi/config.toml:

[registries]
duumbi = "https://registry.duumbi.dev"
company = "https://registry.acme.com"

[workspace]
default-registry = "duumbi"

The default-registry is used when a dependency has no explicit registry field. Scoped packages (@scope/name) automatically route to the registry named scope.

You can also manage registries from the CLI:

duumbi registry add company https://registry.acme.com
duumbi registry list

Searching for modules

From the CLI

duumbi search graph-traverse

This searches all configured registries and prints matching modules with their latest version and description.

From the web UI

Visit your registry in a browser (e.g., registry.duumbi.dev) and use the search bar. You can also press / to focus the search field.

Installing dependencies

Add a dependency to your project:

duumbi deps add @duumbi/stdlib-math

Or specify a version range:

duumbi deps add @duumbi/stdlib-math@^1.2

To install all dependencies defined in config.toml:

duumbi deps install

This resolves versions according to SemVer, downloads .tar.gz archives to .duumbi/cache/, and writes a deps.lock lockfile.

Tip

Use duumbi deps install --frozen in CI to ensure the lockfile is respected exactly — the command will fail if the lockfile is out of date.

Using a dependency from a specific registry

When you have multiple registries, specify which one a dependency comes from:

[dependencies]
"@duumbi/stdlib-math" = "^1.0"
"@company/auth" = { version = "^3.0", registry = "company" }

Publishing a module

1. Prepare your module

Your module directory must contain a manifest.toml with at least name, version, and description:

[module]
name = "@yourscope/my-module"
version = "1.0.0"
description = "A short description of what this module does."

2. Authenticate

If you haven’t already, log in to the registry:

duumbi registry login duumbi

See Authentication for details on login flows.

3. Publish

duumbi publish

This validates the graph, packages it as a .tar.gz archive with a SHA-256 integrity hash, and uploads it to the configured registry.

Tip

Use duumbi publish --dry-run to validate and package without actually uploading. This is useful for checking that everything is correct before publishing.

4. Verify

After publishing, you can verify your module is available:

duumbi search my-module

Or visit the module page on the web UI.

Yanking a version

If you published a broken version, you can yank it. Yanked versions are still downloadable (existing lockfiles continue to work) but won’t be selected for new installs:

duumbi yank @yourscope/my-module@1.0.0

Dependency resolution order

When resolving a module, DUUMBI looks in this order:

1. Workspace — .duumbi/graph/ (local project files)
2. Vendor — .duumbi/vendor/ (pinned, audited copies)
3. Cache — .duumbi/cache/ (downloaded from registry)
4. Not found — error E011

Vendoring for offline builds

Copy dependencies into your project for reproducible, offline builds:

duumbi deps vendor

This copies all cached modules to .duumbi/vendor/. You can commit these to version control.

To vendor selectively:

[vendor]
strategy = "selective"
include = ["@company/*"]