Allow `vp staged` to resolve workspace-root config from subdirectories
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- typescript
Línea de trabajo
Comienza con packages/cli/src/staged/bin.ts, luego lee el recorrido acotado al workspace en packages/cli/src/resolve-vite-config.ts y su uso en packages/cli/src/pack-bin.ts. Reproduce el escenario root-config-from-package descrito anteriormente y, después, establece y valida una única política de resolución de configuración y alcance de ejecución, incluido el caso límite de una configuración de Vite local al paquete.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
In a monorepo, vp staged fails when invoked from a workspace package if the staged config exists only in the workspace-root vite.config.ts.
This is common with coding agents: after inspecting or editing one package, they often keep that package as the working directory when running validation commands.
repo/
├── package.json # workspaces: ["packages/*"]
├── vite.config.ts # contains staged config
└── packages/
└── app/
└── src/index.ts
// repo/vite.config.ts
export default {
staged: {
'*.{js,ts,tsx}': 'vp check --fix',
},
}
git add packages/app/src/index.ts
cd packages/app
vp staged
Actual result:
error: No "staged" config found in vite.config.ts. Please add a staged config
A normal pre-commit hook usually hides this behavior because Git starts client-side hooks from the worktree root, regardless of where git commit was entered.
Current behavior
The following was verified with an isolated Git monorepo:
| Invocation | Config | File/task scope |
|---|---|---|
| Run from repository root | Root vite.config.ts |
Repository |
Run from a package with no local staged config |
None; exits with an error | Nothing runs |
Run from a package with a local staged config |
Package config | Package CWD |
Run from a package with --cwd <workspace-root> |
Root config | Repository |
| Run through a Git pre-commit hook | Root config, because Git uses the worktree root | Repository |
Internally, Vite+ resolves one staged object from the invocation CWD and passes it through lint-staged's programmatic config option. lint-staged still resolves the Git repository and staged files, but its own multi-config discovery is bypassed.
Ecosystem patterns
Existing tools use different models:
| Model | Tools | Behavior |
|---|---|---|
| Hook manager | Git, Husky, simple-git-hooks | Git starts hooks at the worktree root. The manager executes a literal hook command; package-specific CWD or filtering is left to that command. |
| Central root config | pre-commit, Lefthook | The tool resolves the Git root and loads a repository-level config. Package behavior is expressed through filters or per-command root settings. |
| Distributed config | lint-staged | The tool can discover multiple configs, assign each staged file to its closest config, and run tasks from the selected config directory. Configs are isolated rather than merged. |
| Current Vite+ behavior | vp staged |
Git state is repository-aware through lint-staged, while Vite config lookup remains limited to the invocation CWD. |
Relevant details:
- Git changes to the worktree root before client-side hooks: https://git-scm.com/docs/githooks
- Husky requires an explicit
cdwhen a hook should run inside a nested project: https://typicode.github.io/husky/how-to.html#project-not-in-git-root-directory - lint-staged documents closest-config selection, isolated configs, config-directory task CWD, and package scoping with
--cwd: https://github.com/lint-staged/lint-staged#how-to-use-lint-staged-in-a-multi-package-monorepo - Lefthook loads from the Git root and uses a command-level
rootoption to change CWD and filter files; globs remain relative to the Git root: https://lefthook.dev/configuration/root/ - pre-commit resolves the Git top level and changes into it before running most commands: https://github.com/pre-commit/pre-commit/blob/main/pre_commit/main.py#L175-L199
Design choices
There are two separate decisions. This issue does not propose a preferred combination.
1. Where should config come from?
- Current CWD only: preserve existing behavior; improve documentation/error output and require callers to use root CWD or
--cwd. - Workspace/Git root: always use one central root policy.
- Nearest ancestor config: walk upward to the workspace root. This could stop at the first Vite config, or continue until finding one that defines
staged. - Multiple configs: discover package/root staged configs and assign files to them independently.
- Explicit selection: add an option such as
--configor--root; this can supplement any implicit rule.
Important edge case: a package may have a vite.config.ts for build settings but keep staged only at the workspace root. “Nearest Vite config” and “nearest config defining staged” produce different results.
2. What should the execution scope be?
- Repository root: task CWD, glob base, and staged-file scope all use the root.
- Invocation directory: an inherited/root config can be used while files and tasks remain scoped to the package from which the command was launched.
- Config directory: tasks and file matching follow whichever config was selected.
These choices have different consequences. Root scope may process staged files in sibling packages; invocation scope may run root-defined commands from a package CWD; config-directory scope becomes more complex if multiple configs are supported.
Possible combinations include:
- root config + root scope;
- nearest ancestor config + invocation scope;
- current behavior + an explicit config/root option;
- multiple configs + per-config task scope.
Relevant implementation
- Current staged config resolution and inline lint-staged config: https://github.com/voidzero-dev/vite-plus/blob/main/packages/cli/src/staged/bin.ts#L139-L164
- Existing workspace-bounded config traversal: https://github.com/voidzero-dev/vite-plus/blob/main/packages/cli/src/resolve-vite-config.ts#L98-L115
- Existing use of traversal in
vp pack: https://github.com/voidzero-dev/vite-plus/blob/main/packages/cli/src/pack-bin.ts#L148-L150
Validations
- Read the Contributing Guidelines.
- Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
- Checked that there is not already an open issue requesting the same behavior.
- Lenguaje dominante
- Rust
- Estrellas
- 5.8k
- Forks
- 267
- Merge medio
- 20 h 45 min
- PR fusionados (30 d)
- 142
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de voidzero-dev/vite-plus
-
pending triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
voidzero-dev/vite-plus#2854 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
voidzero-dev/vite-plus#2849 ·
Los mantenedores suelen responder en 1 día
-
pending triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
voidzero-dev/vite-plus#2801 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
voidzero-dev/vite-plus#2097 · 10 comentarios · 2 reacciones ·
Los mantenedores suelen responder en 1 día
-
pending triage
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
voidzero-dev/vite-plus#2866 ·
Los mantenedores suelen responder en 1 día
Todos los issues de voidzero-dev/vite-plus
Issues similares
-
bug CLI exec tool-calls
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
maintainer-needed p2 triaged ui windows
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día
-
ai_p2
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
ClickHouse/ClickHouse#123351 ·
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
github/copilot-sdk#2804 · 1 comentario ·
Los mantenedores suelen responder en 1 día