vite-plus: the install script pipes curl to bash, and the v1 tag is stale on purpose

Global install is a curl pipe on Unix and an iex on Windows

There is no npm global install in the getting started section. On Linux or macOS the instruction is a single pipe:

curl -fsSL https://vite.plus | bash

On Windows it is the PowerShell equivalent:

irm https://viteplus.dev/install.ps1 | iex

Both hand a script to the shell from a URL with no checksum, no version pin and no local copy to inspect first. The two hosts differ, vite.plus on the first and viteplus.dev/install.ps1 on the second. That is the price of the single-binary promise, and it is worth noting that the repository also carries a cargo-shear allowlist, a justfile and a bootstrap-cli script, so the project does have the machinery to build the CLI from source when you would rather not trust a pipe. There is a bootstrap-cli script in the package manifest that builds the release CLI, a trampoline and the global install in sequence.

The v1 tag is explicitly retired in the CI setup instructions

The GitHub Actions section is short and contains one instruction that saves people a broken upgrade. Use the official setup-vp action, with node-version and a cache flag, then set the version placeholder to an exact version from the setup-vp releases page. A commit SHA is also acceptable. The sentence that matters is the one after: do not use the v1 tag, because the v1 tag no longer receives updates. So the floating major-version ref, the one most workflows reach for by habit, is deliberately frozen. Pinning an exact version or a SHA is the supported path, and there is a separate guide page for configuring Dependabot or Renovate so those tools do the pinning for you. The example block itself still shows the version placeholder rather than a concrete number, which means a copy-paste will not run until you edit it.

One config file carries Vite, Vitest, Oxlint, Oxfmt and task settings

The configuration surface is a single vite.config.ts at the project root, and the shape of the example shows that it absorbs tools that normally live in separate files. Standard Vite configuration sits under the top level, test configuration holds an include pattern for test files, lint configuration holds ignore patterns, fmt configuration holds formatting options such as semi and singleQuote, and run configuration holds task definitions. A task is a named command with a cache block, and the example caches on an environment variable named ICON_THEME:

run: {
  tasks: {
    'generate:icons': {
      command: 'node scripts/generate-icons.js',
      cache: {
        env: ['ICON_THEME'],
      },
    },
  },
},

So cache invalidation for a task is declared by naming environment variables rather than by listing input and output globs. The migrate command folds tool-specific files such as .oxlintrc variants, .oxfmtrc variants and lint-staged configuration into that one file.

The package manager is detected, and eleven commands forward to it

Vite+ does not replace the package manager, it wraps one, chosen automatically from the packageManager field and from whichever lockfile is present, across pnpm, npm, Yarn and Bun. The command surface for that is a full package manager interface rather than a thin pass-through: add, remove with three aliases, update, dedupe, outdated, list, why with an explain alias, info with view and show aliases, link and unlink, rebuild for native modules, and pm to forward anything else. The aliases are worth noting, since rm, up, ls, explain, view, show and ln are all accepted, and a script written against one package manager may behave differently once wrapped.

The repository builds Rolldown bindings before it builds anything else

The monorepo manifest is named vite-plus-monorepo, is private, declares MIT, and requires Node 22.18.0 or newer with pnpm pinned at 12.11.2. The build script is the interesting line, because it does not start with this project. It builds the rolldown native binding in release mode, then the rolldown node build, then Vite types, and only then the packages under the voidzero scope and vite-plus itself. So the Rust bundler underneath is a build prerequisite of the JavaScript packages, not an optional backend. The lint script goes back through vp itself with type-aware checking, type checking and four threads, and the test script runs vp test and then a snapshot test driven by just. A prepare script runs vp config, which is the piece that writes the git hook dispatcher configuration.

The cargo workspace excludes one crate on purpose

The Rust workspace declares resolver 3, members of bench, a glob over crates, and the CLI binding package, then excludes crates/vp_trampoline and oxc-node. The comment above the exclude explains the vp_trampoline case: vp_trampoline is a standalone package, it needs a separate release profile and a crate-local build-std configuration, and cargo ignores panic in per-package profile overrides. That last detail is the kind of thing that costs an afternoon, and it is recorded in the manifest rather than in a wiki. The workspace package block pins edition 2024 and a rust-version of 1.92.0, which is a high floor, and the clippy lint table sets all at warn with priority minus one, and the Rust lint table allows deprecated and unfulfilled_lint_expectations with comments tied to oxc and rolldown.

Two release candidates and a 1.0 inside six days

The release history moves quickly: v1.2.0 landed on 2026-10-14, v1.3.0 on 2026-10-16 and v1.4.0 on 2026-10-23. The last push to the default branch was on 2026-11-02, the repository is not archived, and the project states it is fully open-source under the MIT license.

Editorial conclusion

vite-plus suits a team that has already standardised on the Vite ecosystem and wants one binary to install, lint, test, build and run monorepo tasks, and the consolidation is real since the same config file covers all of it. Three things to settle first. The installation is a pipe from the network into a shell, so read the script before running it in CI, and the Windows path pipes a PowerShell script into iex. The package manager is detected rather than chosen, so make sure your packageManager field and lockfile agree with what you actually want wrapped. And the CLI is a moving target: v1.2.0, v1.3.0 and v1.4.0 landed within ten days of each other in October 2026, so pin vp itself in CI the way the setup-vp action docs tell you to. A team that wants a bundler and nothing else will find this opinionated in a way plain Vite is not.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes