vlt v1.8.0: installs with no setup and simpler registry resolution

vlt v1.8.0 installs packages with no setup, through a built-in public npm mirror, and resolves dependencies that have no registry prefix from your own configuration.

vlt v1.8.0 release
Author
Published
Tags
vltclientfeatures

vlt v1.8.0 is out, and vlt install now works right after you install vlt. Earlier versions had no default registry, so on a new machine every install failed with Missing registry configuration until you ran vlt setup or set registries.npm yourself. The npm registry alias now has a built-in URL, vlt's public npm mirror, which needs no account and no token. vlt install, vlx, vlt view and the other commands that only read from a registry use it when nothing else is configured. A registry you already configured still takes precedence, so existing setups work as before.

The other highlight is how vlt picks the registry for the dependencies of your dependencies. A dependency written without a registry prefix used to be fetched from the registry its parent came from, whenever that parent was installed through an alias, a scope mapping, jsr: or gh:. That broke installs from private registries that don't also serve public packages, and it could install a second copy of a peer dependency. Those dependencies now resolve from your own configuration at any depth, which is how npm, pnpm, Yarn, Bun and Deno do it.

Changes

  • The default registry is vlt's public npm mirror. With no configuration, package metadata and tarballs are requested from https://registry.vlt.io/upstream/npm/.
  • vlt setup is optional. It is still the recommended next step: vlt setup connects vlt to your vlt.io account, which comes with an npm mirror that has no usage limits and a private registry for your own packages.
  • Publishing needs a registry you configure. The public mirror is read-only, so vlt publish, vlt login, vlt whoami, vlt token, vlt dist-tag and the other commands that write or authenticate never use it. Without a configured registry they stop with an error that points to vlt setup, --registry and publishConfig.registry.
  • A notice on first use, and advice at the usage limit. The public mirror is a shared service with usage limits. The first command that installs through it prints a notice saying so, once per machine, and never in CI. A request that goes over the limits fails with advice to run vlt setup or to set another registries.npm.
  • Lockfiles leave out the built-in registry. A vlt-lock.json written on the default records no npm registry URL, so vlt ci also accepts it on a machine that uses an account mirror. A lockfile that pinned registries.npm to the mirror's URL drops that entry the next time it is saved. Versions before v1.8.0 can't install from such lockfiles, so update vlt everywhere the project is installed, CI included.
  • jsr: packages with npm dependencies install. vlt install jsr:@oak/oak failed with a 404, because its path-to-regexp dependency was requested from the JSR registry. @jsr/* dependencies now come from JSR and everything else from your npm registry.
  • Private packages can depend on public ones. With a scope like @acme mapped to a private registry in scoped-registries, a private package with a public dependency failed with a 404 unless that registry also served public packages. The public dependency now comes from your default registry.
  • Peer dependencies resolve to the copy you already have. A peer dependency declared by a package from a private registry was looked up on that registry, which ended in a 404 or in a second copy of a package the project already had. It now resolves to the project's copy.
  • An alias applies only to the package it names. corp:internal-lib picks the registry for internal-lib, not for its dependencies. If you relied on those coming from the same registry, map their scope in scoped-registries or make that registry your default.
  • A clearer 404. When a dependency without a prefix isn't found on your default registry and its parent came from another one, the error names both registries and says how to install the dependency from its parent's registry.
  • Lockfiles from earlier versions are kept as they are. An unchanged project installs what is locked. The next time those dependencies are resolved, for example after adding a dependency or running vlt update, they follow the new rule.

Try it

You can find every patch note in the GitHub releases. To install or update vlt, run:

Terminal

curl -fsSL https://install.vlt.sh | bash

Already on vlt? Run vlt install -g vlt to update.