Wrap your package manager

Shadow npm / pnpm / yarn / bun with vis so every install runs through the marshall pipeline.

Wrap your package manager

vis install and vis add pass unknown subcommands straight through to the detected package manager (npm, pnpm, yarn, bun) but run the marshall pipeline first — typosquats, downloads, archived repos, expired domains, dist signatures, provenance, the s1ngularity compromised-publish shape, new bin scripts, metadata, and author/publisher heuristics. The cleanest way to get that protection on every install is to alias your package manager to vis.

Bash / Zsh

Add to ~/.bashrc or ~/.zshrc:

alias npm='vis'
alias pnpm='vis'
alias yarn='vis'
alias bun='vis'

Reload (source ~/.bashrc) and your existing muscle memory keeps working — npm install, pnpm add foo, yarn upgrade, etc., all flow through vis.

Fish

~/.config/fish/config.fish:

alias npm 'vis'
alias pnpm 'vis'
alias yarn 'vis'
alias bun 'vis'

Per-project (mise / direnv / nix-shell)

Drop a one-line wrapper script into a tools directory you already shim onto PATH. For mise:

# .mise.toml
[hooks]
enter = "alias npm='vis' && alias pnpm='vis' && alias yarn='vis' && alias bun='vis'"

For direnv:

# .envrc
alias npm='vis'
alias pnpm='vis'
alias yarn='vis'
alias bun='vis'

What passes through

vis install <args…> and vis add <args…> are the integration points:

  • Marshalls fire first. Each pre-install marshall (see below) runs against the named packages. Errors abort the install; warnings show a 15-second countdown you can cancel with Ctrl-C.
  • Then vis hands off to the detected package manager with the original args. vis install --frozen-lockfile --prod becomes pnpm install --frozen-lockfile --prod (or npm ci --omit=dev, etc.) when pnpm is the detected PM.

The detection cascades: explicit packageManager field in package.json → lockfile → corepack → $PATH. Override with --pm.

Skipping checks

Per-invocation:

vis add lodash --no-typosquat-check          # skip the typosquat marshall only
VIS_DISABLE_AUTO_CONTINUE=1 vis add lodash   # require explicit y/N on warnings
MARSHALL_DISABLE_ALL=1 vis add lodash         # disable every marshall (emergency escape hatch)

Per-marshall, by environment variable:

MarshallEnv var
typosquatsMARSHALL_DISABLE_TYPOSQUATS=1
installScriptsMARSHALL_DISABLE_INSTALL_SCRIPTS=1
firstSeenMARSHALL_DISABLE_FIRST_SEEN=1
publisherChangeMARSHALL_DISABLE_PUBLISHER_CHANGE=1
scoreMARSHALL_DISABLE_SCORE=1
malwareMARSHALL_DISABLE_MALWARE=1
vulnerabilityMARSHALL_DISABLE_VULNERABILITY=1
licenseMARSHALL_DISABLE_LICENSE=1
unexpectedDepsMARSHALL_DISABLE_UNEXPECTED_DEPS=1
authorMARSHALL_DISABLE_AUTHOR=1
expiredDomainsMARSHALL_DISABLE_EXPIRED_DOMAINS=1
signaturesMARSHALL_DISABLE_SIGNATURES=1
provenanceMARSHALL_DISABLE_PROVENANCE=1
s1ngularityMARSHALL_DISABLE_S1NGULARITY=1
newBinMARSHALL_DISABLE_NEW_BIN=1
downloadsMARSHALL_DISABLE_DOWNLOADS=1
metadataMARSHALL_DISABLE_METADATA=1
archivedRepoMARSHALL_DISABLE_ARCHIVED_REPO=1

Per-project, in vis.config.ts:

export default {
    security: {
        author: { enabled: false },
        expiredDomains: { allowDomains: ["legacy-corp.example"] },
        downloads: { allowlist: ["@myorg/private-pkg"], warnThreshold: 1000 },
    },
};

Pre-flight without installing

For one-off vetting, vis inspect runs the marshall pipeline against a package without touching the lockfile:

vis inspect express
vis inspect lodash@4.17.21
vis inspect express --json | jq '.findings[]'
vis inspect express --strict      # exit non-zero on warnings too
vis inspect express --only author,downloads

Use it in code review (vis inspect <new-dep> before merging a PR that adds a dependency) or in CI for vetting third-party additions.

Verifying the alias

which npm           # → alias to vis
vis --version
vis inspect lodash  # smoke test that the pipeline runs

If which npm still shows the real npm binary, your alias wasn't sourced — check the alias is in the correct shell config and that you've re-opened your shell.

Support

Contribute to our work and keep us going

Community is the heart of open source. The success of our packages wouldn't be possible without the incredible contributions of users, testers, and developers who collaborate with us every day.Want to get involved? Here are some tips on how you can make a meaningful impact on our open source projects.

Ready to help us out?

Be sure to check out the package's contribution guidelines first. They'll walk you through the process on how to properly submit an issue or pull request to our repositories.

Submit a pull request

Found something to improve? Fork the repo, make your changes, and open a PR. We review every contribution and provide feedback to help you get merged.

Good first issues

Simple issues suited for people new to open source development, and often a good place to start working on a package.
View good first issues