Install and upgrade

Try it

cargo binstall vivace
viv install     # in a project with composer.json and composer.lock

That also installs a composer shim next to viv; put it first on PATH and your existing scripts run through viv unedited (see Using viv as composer).

Prebuilt binaries are on the releases page (Linux x86_64 as glibc and static musl builds, aarch64 as static musl, also packaged as a .deb; macOS x86_64 and aarch64). To build from source instead:

cargo install vivace --locked

Both commands also upgrade an existing install: binstall only downloads when the release is newer than the one installed; add --force to cargo install when the version has not changed.

If Composer already wrote the vendor/ directory, viv adopts it automatically, no flag needed. Only composer install run through the shim asks for confirmation first, and only in a terminal. If a package can't be downloaded (a private package behind a licence key, for example), viv keeps Composer's copy of that package, prints a warning, and adopts the rest. To force a fresh relink of a vendor/ that viv itself wrote, run viv install --adopt.

Starting from nothing

No composer.json yet? viv init writes one and stops, with no prompts: the package name is guessed from git config user.name and the directory, type is project, license is MIT, and autoload.psr-4 points at src/ when that directory exists. Pass --name, --license or --type to override a default, or --require/--require-dev to add dependencies in the same command:

mkdir demo && cd demo && viv init --require psr/log

That resolves psr/log, writes composer.lock, and installs vendor/, the same as viv add would on an existing project (--no-install opts out). Run it again with --force to start over.

viv init is for the directory you're already in; viv new is for one that doesn't exist yet. A bare name creates it and runs init's own defaults inside:

viv new demo

vendor/package[:constraint] downloads that package's dist as a project skeleton (constraint defaults to the newest stable version), drops its own VCS metadata, and installs it, running the post-root-package-install/ post-create-project-cmd scripts a skeleton like Laravel's relies on (--no-scripts opts out):

viv new laravel/laravel:^11 my-app

create-project is Composer's own name for this, kept as an alias.

Stopping

You can stop using viv at any point and go back to Composer with no clean-up. A vendor/ that viv wrote is a valid Composer install: installed.json and the autoload files are the same bytes Composer would have written, so composer install on it is a no-op and composer update replaces packages as usual. The only extra file is a small state file in vendor/composer/, which Composer ignores.

The links from vendor/ into viv's store are hardlinks, not symlinks: each file in vendor/ is a real file that shares its data with the store copy, so deleting the store (viv cache clean) leaves vendor/ complete and working. If you would rather reinstall it with Composer anyway:

rm -rf vendor && composer install

To remove viv itself:

viv cache clean            # deletes viv's store under ~/.cache/vivace
rm ~/.cargo/bin/viv ~/.cargo/bin/composer   # the binary and the shim

Use apt remove vivace if you installed the .deb instead. Nothing else is written outside the project and the cache.

Prebuilt binaries and the .deb

Linux and macOS binaries, including a .deb package, are covered above in Try it: the README lists the exact platforms and architectures.