`vp config` / `vp hooks enable` skip a clone where husky set `core.hooksPath`

Start in packages/cli/src/config/hooks.ts, where install() skips an existing core.hooksPath, and inspect the command_config_replace_husky_hookspath snapshot referenced in the issue. Reproduce with the provided script using .husky/_, then compare the behavior when core.hooksPath is unset. Done means the intended husky migration behavior is decided and covered by a test showing whether Vite+ installs its dispatcher.

Describe the bug

After a repo moves from husky to Vite+ Git hooks (husky removed, .husky/commit-msg moved to .vite-hooks/commit-msg, "prepare": "vp config"), every existing clone still has core.hooksPath=.husky/_, which husky set. In those clones vp install (through prepare), vp config, vp config --hooks and vp hooks enable all print:

core.hooksPath is already set to ".husky/_", skipping

core.hooksPath stays .husky/_, no hook runs, and nothing exits non-zero. Only fresh clones get working hooks, so a migration quietly turns hooks off for everyone who already had the repo checked out.

The skip comes from install() in packages/cli/src/config/hooks.ts: any effective core.hooksPath that isn't the Vite+ target is left alone. #772 used to replace .husky/_ / .husky, but #2280 changed that, and the command_config_replace_husky_hookspath snapshot now expects the husky path to be kept. The docs say the same ("If core.hooksPath points to another hook directory, vp config skips dispatcher installation").

Expected: .husky/_ is a dispatcher husky generated, not one the project owns, and Vite+ already accepts husky's HUSKY=0 and husky/init.sh. So vp config / vp hooks enable should take over a .husky/_ (or .husky) hooksPath, at least when the project no longer depends on husky. Failing that, vp hooks enable --force (and something similar for vp config) would let prepare take it over explicitly. Explicit vp hooks enable has no way to override the skip today.

Reproduction

Self-contained script below (no repo needed).

Steps to reproduce

Run with bash repro.sh. It builds a throwaway repo in a temp dir with .vite-hooks/commit-msg (rejects messages not starting with feat), sets core.hooksPath the way husky leaves it, runs the commands and attempts a bad commit. bash repro.sh --unset clears core.hooksPath first, for contrast.

#!/usr/bin/env bash
# Usage: repro.sh [--unset]   (--unset clears core.hooksPath before installing)
set -u
VP_VERSION="${VP_VERSION:-1.4.0}"
DIR="$(mktemp -d)"; cd "$DIR"

git init -q
cat > package.json <<JSON
{
  "name": "hookspath-repro",
  "private": true,
  "packageManager": "[email protected]",
  "scripts": { "prepare": "vp config" },
  "devDependencies": { "vite-plus": "$VP_VERSION" }
}
JSON
mkdir -p .vite-hooks
cat > .vite-hooks/commit-msg <<'HOOK'
#!/usr/bin/env sh
head -1 "$1" | grep -q '^feat' || { echo "commit-msg hook: rejected" >&2; exit 1; }
HOOK
chmod +x .vite-hooks/commit-msg

# What husky leaves behind in an existing clone
git config core.hooksPath .husky/_
mkdir -p .husky/_
[ "${1:-}" = "--unset" ] && git config --unset core.hooksPath

show() { echo "   core.hooksPath = $(git config --get core.hooksPath || echo '<unset>')"; }
echo "$ vp install";            vp install 2>&1 | grep -iE 'hooksPath|prepare|vp config|error' ; show
echo "$ vp --version";          vp --version | sed -n '1,4p'
echo "$ vp config";             vp config --no-agent 2>&1; show
echo "$ vp config --hooks";     vp config --hooks --no-agent 2>&1; show
echo "$ vp hooks enable";       vp hooks enable 2>&1; show

git add -A
echo "$ git commit -m 'bad message'"
if git -c user.name=repro -c [email protected] commit -q -m "bad message" 2>&1; then
  echo "=> commit SUCCEEDED (hook did not run)"
else
  echo "=> commit REJECTED by hook"
fi
rm -rf "$DIR"

Output with husky's hooksPath (bash repro.sh):

$ vp install
> hookspath-repro@ prepare <tmpdir>
> vp config
core.hooksPath is already set to ".husky/_", skipping
   core.hooksPath = .husky/_
$ vp --version
vp v1.1.0

Local vite-plus:
  vite-plus  v1.4.0
$ vp config
core.hooksPath is already set to ".husky/_", skipping
   core.hooksPath = .husky/_
$ vp config --hooks
core.hooksPath is already set to ".husky/_", skipping
   core.hooksPath = .husky/_
$ vp hooks enable
core.hooksPath is already set to ".husky/_", skipping
   core.hooksPath = .husky/_
$ git commit -m 'bad message'
=> commit SUCCEEDED (hook did not run)

Output with bash repro.sh --unset:

$ vp install
> hookspath-repro@ prepare <tmpdir>
> vp config
   core.hooksPath = .vite-hooks/_
$ vp --version
vp v1.1.0

Local vite-plus:
  vite-plus  v1.4.0
$ vp config
   core.hooksPath = .vite-hooks/_
$ vp config --hooks
   core.hooksPath = .vite-hooks/_
$ vp hooks enable
Git hook dispatcher installed at .vite-hooks/_
   core.hooksPath = .vite-hooks/_
$ git commit -m 'bad message'
commit-msg hook: rejected
VITE+ - commit-msg script failed (code 1)
=> commit REJECTED by hook

Workaround: clear husky's value before vp config in prepare:

"prepare": "git config --get core.hooksPath | grep -q '^\\.husky' && git config --unset core.hooksPath; vp config"

System Info

$ vp --version
vp v1.1.0

Local vite-plus:
  vite-plus  v1.4.0

Tools:
  vite             v8.3.5
  rolldown         v1.2.15
  vitest           v5.0.5
  oxfmt            v0.74.0
  oxlint           v1.89.0
  oxlint-tsgolint  v7.0.2004
  tsdown           v0.23.1

Environment:
  Package manager  pnpm v10.20.0
  Node.js          v24.19.0

$ vp env current
Node.js:
  Version    24.19.0
  Source     default
  Mode       managed

Package Manager:
  Name       pnpm
  Version    10.20.0
  Source     packageManager
  Mode       system_first

OS: Ubuntu 26.04.1 LTS (Linux 7.0.0 x86_64), git 2.53.0

vite-plus 1.4.0 is the latest release (npm latest dist-tag) as of this report.

Used Package Manager

pnpm

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue.
• The provided reproduction is a minimal reproducible example.

Written by claude-opus-5-5 via Claude Code in T3 Code on goobles-agentbox.