`extends` in `defineConfig`

Description

I’d like to add a field extends for defineConfig like this:

import commonConfig from '@company/vite-config-common'

export default defineConfig({
  extends: [commonConfig]
})

It would help us unify and simplify the vite config files in our projects.

Suggested solution

The semantics of extends can be identical to mergeConfig. We can allow using package name directly in extends for convenience.

Alternative

1. mergeConfig Adding extends field is more simple and constrained than letting users use mergeConfig directly in their config files. Besides, mergeConfig is an undocumented API.

2. abstract over vite defineConfig Wrap around vite like:

// @mycompany/wrapped-vite/index.ts
import { mergeConfig, defineConfig } from 'vite'
const commonConfig = ...
export const defineConfig: typeof defineConfig = (...args) => mergeConfig(commonConfig, defineConfig(...args))

// user-project/vite.config.ts
import { defineConfig } from '@mycompany/wrapped-vite'
export default defineConfig({...})

It works but we think it’s better to add this ability directly to vite rather than wrap it.

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

[bluwy]

mergeConfig and many exposed APIs are always public, but we expose a lot of APIs to fit in the docs so it only shows the commonly used ones. I think using mergeConfig is the way to go here. If we implement extends it’ll very likely be the same as mergeConfig, and it’s better to have one way of doings things. Plus doing it in-code makes it easier to reason how data is passed around.

[lsdsjy]

https://github.com/vitejs/vite/pull/8999 It seems that Vite now documents mergeConfig as an public API. Though I still don’t want users of my common config uses mergeConfig directly, this feature request is more unnecessary now.😅