Support a dedicated config file for vp run tasks (Turborepo-style turbo.json)

[gkweb]

Description

Currently, vp run task definitions, inputs, and caching behaviour are configured inside vite.config.ts under the run key. I'd like to propose first-class support for splitting this out into a dedicated config file — either a JSON file similar to Turborepo's turbo.json, or a dedicated vp.config.ts (naming TBD).

I really like Turborepo's DX of having a single, dedicated file that describes the task graph, inputs, outputs, and cache behaviour for the whole repo. A few things make that approach nice to work with:

• Separation of concerns — Vite build/dev config and monorepo task orchestration are conceptually different things. Bundling them into one file means vite.config.ts grows quickly in larger monorepos.
• Discoverability — a dedicated file (vp.json / vp.config.ts) signals "this is how tasks and caching work in this repo" at a glance, without having to scroll past Vite plugin config.
• Tooling friendliness — a JSON variant (with a published schema) would be easy for editors, CI tools, and codegen to reason about, similar to turbo.json or tsconfig.json.
• Mental model — vp is positioned as the unified entry point, so it feels natural for it to have its own config surface rather than always living inside Vite's.

Suggested solution

Either (or both) of:

• vp.json — a JSON config for the run/task layer, schema-backed, suitable for repos that don't need programmatic config.
• vp.config.ts — a TS config using defineConfig from vite-plus, for repos that want types and dynamic logic.

Existing run config inside vite.config.ts could continue to work for backwards compatibility, with the dedicated file taking precedence (or merging) when present.

Alternative

No response

Additional context

No response

Validations

• Read the Contributing Guidelines.
• Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
• Check that there isn't already an issue requesting the same feature.

[fengmk2]

You can create an arbitrary ts file as a configuration file for run tasks, and then import it through vite.config.ts to set it under the run field configuration. You can try this approach first.

[gkweb]

You can create an arbitrary ts file as a configuration file for run tasks, and then import it through vite.config.ts to set it under the run field configuration. You can try this approach first.

Yeah but it would be good to have this simple setup ported to a convention as proposed.

I'm happy to open a PR.

For context in my use case - This is to cover a mono repo with 50+ vite config files across packages and apps.

It's just cleaner to have the dedicated file.

[RobbyRabbitman]

Please no json files - js files are really powerful imo as you can have shared configs and distribute them even outside a workspace. This is so huge for monorepos and organizations maintaining a tooling stack. By doing so you don't have large vite.config.ts files. I come from nx workspaces and while the current version misses some features (but I guess those will be shipped eventually), the DX is so much better already. In addition js files enable dynamic tasks e.g. inferring tasks based on conventions or whatever without the authors of vp needing to come up with a solution for that. Just my opinion.

[RobbyRabbitman]

You can create an arbitrary ts file as a configuration file for run tasks, and then import it through vite.config.ts to set it under the run field configuration. You can try this approach first.

Yeah but it would be good to have this simple setup ported to a convention as proposed.

I'm happy to open a PR.

For context in my use case - This is to cover a mono repo with 50+ vite config files across packages and apps.

It's just cleaner to have the dedicated file.

There already is a convention, it's the interface of the run property, no?

[gkweb]

Please no json files - js files are really powerful imo as you can have shared configs and distribute them even outside a workspace. This is so huge for monorepos and organizations maintaining a tooling stack. By doing so you don't have large vite.config.ts files. I come from nx workspaces and while the current version misses some features (but I guess those will be shipped eventually), the DX is so much better already. In addition js files enable dynamic tasks e.g. inferring tasks based on conventions or whatever without the authors of vp needing to come up with a solution for that. Just my opinion.

I'm not disagreeing with the power that a .js/.ts file provides but JSON is static and declarative. For caching specifically - The cache key is a pure function of the config + inputs. The moment you let people compute cache behaviour dynamically in TS, you've made cache invalidation observably non-deterministic, which is exactly the bug-farm nx or turborepo avoids by being JSON-only?

[RobbyRabbitman]

The authoring side is not affected whether userland uses json or js files, is it? The current run.tasks interface is json serializable, but even if they allowed callbacks: are those userland sideeffects a concern?