Yazi ya¶

ID: yazi
Home page: https://yazi-rs.github.io
Version requirement: >= 25.2.7
Platforms: 🅱️ BSD · 🐧 Linux · 🍎 macOS · ⨂ Unix · 🪟 Windows
Operations: installed · install · upgrade · upgrade_all · remove
purl types: pkg:yazi
CLI name: ya
Issues and PRs: 📦 manager: yazi
Source: meta_package_manager/managers/yazi.toml

yazi is a terminal file manager (https://yazi-rs.github.io), and what is wrapped here is the package manager of its command-line companion, ya.

The manager is ya, not yazi: the file manager itself is the interactive program, while ya is the non-interactive half of the same release, shipping in the same archive and carrying the package verbs. That is what makes this drivable with nobody at the keyboard, where an interactive file manager would not be.

Note

Packages come in two kinds and one listing covers both. A plugin extends the file manager’s behavior and a flavor themes it; ya pkg list prints them under a Plugins: and a Flavors: heading respectively. Both are addressed by the same owner/repo:name identifier and act the same way, so mpm reports one flat inventory and the headings are simply not matched: only the tab-indented entries below them are, which is what skips the headings without a rule of their own.

Note

The version is a short Git commit, not a release. yazi packages are Git subdirectories rather than published artifacts, so the revision a package is checked out at is the only version there is, exactly as it is for the Neovim plugin managers mpm wraps.

No outdated: nothing reports a remote revision without also fetching it. ya pkg upgrade compares and updates in one step, and no flag stops it after the comparison. upgrade --all is unaffected.

No search: yazi has no catalog command. Packages are named by their Git coordinates, and the curated list lives on the project’s website rather than behind a CLI.

No sync and no cleanup: nothing refreshes an index without acting, and nothing prunes a cache.

No escalation: packages live under the user’s own cache directory, which follows the XDG cache home before falling back to ~/.cache/yazi.

No logo is declared: Simple Icons carries no mark for yazi, so the manager page keeps its default package glyph rather than borrowing an unrelated one.

What `mpm` adds to `yazi`¶

mpm reaches across every manager at once, not yazi alone: mpm installed and mpm outdated cover yazi alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your `yazi` commands, in `mpm`¶

You already know yazi: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…	With `yazi`	With `mpm`
List what’s installed	`ya pkg list`	`mpm --yazi installed`
Install a package	`ya pkg add <package_id>`	`mpm install pkg:yazi/<package_id>`
Upgrade one package	`ya pkg upgrade <package_id>`	`mpm --yazi upgrade <package_id>`
Upgrade everything	`ya pkg upgrade`	`mpm --yazi upgrade --all`
Remove a package	`ya pkg delete <package_id>`	`mpm remove pkg:yazi/<package_id>`

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations¶

Operation	Supported
`installed`	✓
`outdated`
`orphans`
`search`
`install`	✓
`upgrade`	✓
`upgrade_all`	✓
`remove`	✓
`sync`
`cleanup`
`doctor`

Selecting and configuring `yazi`¶

Deselect yazi for a single run with --no-yazi, or persist the choice in your configuration:

[mpm]
yazi = false

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.yazi]
timeout = 900

mpm config-template yazi prints every overridable attribute as a ready-to-paste block.

Recipes¶

A few jobs you would otherwise script around yazi, one mpm command each:

Snapshot and clone a machine: mpm --yazi dump yazi.toml, then mpm restore yazi.toml on the next one.
Export a compliance SBOM: mpm --yazi sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation¶

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

None of its operations needs root.

See privilege escalation for the full policy.

Cooldown¶

State of Yazi ya’s release-age gating, from the cooldown support table:

Status: ❌ None

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

Registry: Upstream Git clones
Retraction: None: a plugin is cloned straight from its upstream repository, so withdrawing a bad revision is its author force-pushing, retagging or deleting it themselves. No index sits in between
Publish date: ❌ a commit or tag date is set by the author and freely rewritable

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.

Version probe¶

The version is probed by running:

$ ya --version
Ya 26.5.6 (aa52643 2026-05-05)

and extracted with:

r"^Ya[ \t]+(?P<version>\S+)"

Reference traces¶

Raw native outputs captured in the bundled definition: the reference mpm’s parsers were written against. If you know Yazi ya well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ ya pkg list
Plugins:
	yazi-rs/plugins:full-border (3f2b882)
Flavors:
	yazi-rs/flavors:catppuccin-mocha (be0b21d)

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --yazi installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog¶

7.7.0.dev0 (unreleased)
- Implement yazi, the package manager of the ya command-line companion to the Yazi file manager. Plugins and flavors are reported as one inventory, each identified by its Git coordinates and versioned by the commit it is checked out at.