extends in defineConfig

[lsdsjy]

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.

[lmiller1990]

Can't you just do a merge?

import { common } from './common.config'

export default defineConfig({
   ...common,
   {
      // other config
  }
})

Then you can selectively override things. The obvious complexity with extends is how things are merged - since this is JS module, not json, I don't think extends makes sense. extends is normally in json configs, where you cannot do a merge, since the code is not a module.

[lsdsjy]

Using object spread syntax would overwrite fields, e.g.

const commonConfig = {
    resolve: {
        alias: [
            {
                find: '@',
                replacement: path.resolve(__dirname, 'src'),
            },
        ]
    }
}
export default defineConfig({
    ...commonConfig,
    resolve: {
        alias: [...]
    }
})

The whole resolve field in the commonConfig would be lost. The semantics of extends is more like deepMerge.
In fact, merging configs is already implemented in mergeConfig which is exported by vite. All we need to do is make it public, in a more declarative and constrained fashion.

[lmiller1990]

Right, you'd need to do more effort:

const commonConfig = {
    resolve: {
        alias: [
            {
                find: '@',
                replacement: path.resolve(__dirname, 'src'),
            },
        ]
    }
}
export default defineConfig({
    ...commonConfig,
    resolve: {
        alias: [...commonConfig.alias, ...newAliases]
    }
})

Not clean, for sure. I have not looked, but how does Vite implement merging under the hood? Is it just something like https://www.npmjs.com/package/deepmerge? I wonder if that would work for you, if the Vite team doesn't want to expose and document extends.

[lsdsjy]

#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.😅

[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.