You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow vp config to install hooks without forcing vp staged #2252
At the present, vp config forces the hooks must include vp staged. That said, you can still modify your <project-root>/.vite-hooks/pre-commit to add other commands.
Like
vp staged
vp run lint
vp exec tsc --noEmit
It is just a small .includes('vp staged') string match, so there is a small workaround if you don't really want to use vp staged
# vp staged
vp run lint
vp exec tsc --noEmit
Considering the current vp config's behavior is documented and expected. I will treat it as a feature request :), and I think it is worth supporting!
@liangmiQwQ, I still consider it a bug. I don't want to use "staged" at all, only commands in the hooks, similar to husky, but vp config is forcing it:
Yes, vp install, which one is triggering prepare. It looks like the empty staged also works. For some reason, the absence of this option generates a new rule on vp install right after a fresh clone, even if the config file exists.
vp config should only install and refresh the generated hook dispatcher under .vite-hooks/_. It should not modify hooks such as .vite-hooks/pre-commit and does not write to vite.config.ts.
Top-level .vite-hooks/* scripts are project-owned and live in the repo (committed), while .vite-hooks/_/* stays ignored and is recreated after installation
vp create can continue scaffolding a default vp stagedpre-commit hook and staged configuration when the user opts into that workflow
vp migrate should preserve or translate existing behavior (e.g. from husky) and only introduce defaults when there is no existing hook policy
That would allow custom hooks without requiring an empty staged configuration or a new opt-out flag.
@TheAlexLichter, yes. It sounds exactly like how husky works right now. Currently, I have a config just for an empty staged: {} as a workaround for hooks.
Activity
liangmiQwQ commentedon Jul 27, 2026
Hello!
At the present,
vp configforces the hooks must includevp staged. That said, you can still modify your<project-root>/.vite-hooks/pre-committo add other commands.Like
vp staged vp run lint vp exec tsc --noEmitIt is just a small
.includes('vp staged')string match, so there is a small workaround if you don't really want to usevp stagedConsidering the current
vp config's behavior is documented and expected. I will treat it as a feature request :), and I think it is worth supporting!Perdolique commentedon Jul 27, 2026
@liangmiQwQ, I still consider it a bug. I don't want to use "staged" at all, only commands in the hooks, similar to
husky, butvp configis forcing it:The config (or lacking of a config file at all)
becomes
every time a new user clones the repo. This section should be optional. At the moment, it's a blocker for migration from
husky.As a workaround, I did:
But it looks like an unnecessary crutch, to be honest 🤔.
liangmiQwQ commentedon Jul 27, 2026
cc @TheAlexLichter
liangmiQwQ commentedon Jul 27, 2026
Cloning repo itself shouldn't trigger git hooks. Maybe you mean
vp install?@Perdolique Maybe you can try leave an empty object for
staged, likestaged: {}.Perdolique commentedon Jul 27, 2026
Yes,
vp install, which one is triggeringprepare. It looks like the emptystagedalso works. For some reason, the absence of this option generates a new rule onvp installright after a fresh clone, even if the config file exists.TheAlexLichter commentedon Jul 27, 2026
How about this:
.vite-hooks/_. It should not modify hooks such as.vite-hooks/pre-commitand does not write tovite.config.ts..vite-hooks/*scripts are project-owned and live in the repo (committed), while.vite-hooks/_/*stays ignored and is recreated after installationvp createcan continue scaffolding a defaultvp stagedpre-commithook and staged configuration when the user opts into that workflowvp migrateshould preserve or translate existing behavior (e.g. from husky) and only introduce defaults when there is no existing hook policyThat would allow custom hooks without requiring an empty staged configuration or a new opt-out flag.
Perdolique commentedon Jul 27, 2026
@TheAlexLichter, yes. It sounds exactly like how
huskyworks right now. Currently, I have a config just for an emptystaged: {}as a workaround for hooks.fix(cli): preserve project-owned git hooks (#2280)