-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ResolvedConfig
interface
#15473
Comments
still looking for this fix. |
While your suggestion seems reasonable, can you elaborate your use case? What I'm wondering is that, since extending As an example, Vitest extends |
If there's no breaking changes to switching to an interface, I think it'll be nice to do so. I personally tend to prefer interface but it looks like the source code now has a mix of interface and type, so it's not very consistent to side towards a pattern. |
Make // assume vite custom plugin interface
type CustomContext = Record<string, any>;
type ResolvedCustomConfig = Record<string, any>;
declare module "vite" {
export interface UserConfig {
__customPluginContext?:
| {
customPluginConfig?: Partial<ResolvedCustomConfig>;
}
| Partial<CustomContext>;
}
export interface ResolvedConfig {
__customPluginContext: CustomContext;
}
}
export {}; |
Why not use an interface? export interface ResolvedConfig extends Readonly<
Omit<
UserConfig,
| 'plugins'
| 'css'
| 'json'
| 'assetsInclude'
| 'optimizeDeps'
| 'worker'
| 'build'
| 'dev'
| 'environments'
| 'server'
| 'preview'
> & {
configFile: string | undefined
configFileDependencies: string[]
inlineConfig: InlineConfig
root: string
base: string
/** @internal */
decodedBase: string
/** @internal */
rawBase: string
publicDir: string
cacheDir: string
command: 'build' | 'serve'
mode: string
isWorker: boolean
// in nested worker bundle to find the main config
/** @internal */
mainConfig: ResolvedConfig | null
/** @internal list of bundle entry id. used to detect recursive worker bundle. */
bundleChain: string[]
isProduction: boolean
envDir: string
env: Record<string, any>
resolve: Required<ResolveOptions> & {
alias: Alias[]
}
plugins: readonly Plugin[]
css: ResolvedCSSOptions
json: Required<JsonOptions>
esbuild: ESBuildOptions | false
server: ResolvedServerOptions
dev: ResolvedDevEnvironmentOptions
/** @experimental */
builder: ResolvedBuilderOptions | undefined
build: ResolvedBuildOptions
preview: ResolvedPreviewOptions
ssr: ResolvedSSROptions
assetsInclude: (file: string) => boolean
logger: Logger
createResolver: (options?: Partial<InternalResolveOptions>) => ResolveFn
optimizeDeps: DepOptimizationOptions
/** @internal */
packageCache: PackageCache
worker: ResolvedWorkerOptions
appType: AppType
experimental: ExperimentalOptions
environments: Record<string, ResolvedEnvironmentOptions>
/** @internal */
fsDenyGlob: AnymatchFn
/** @internal */
safeModulePaths: Set<string>
} & PluginHookUtils
> {} |
Description
ResolvedConfig
is currently defined as a type, but it should be an interface.Unlike with
UserConfig
, this means declaration merging cannot be taken advantage of by plugin developers. As a TypeScript developer, this makes typing resolved plugin options unnecessarily difficult. Sharing those options with other plugin developers is not possible without declaration merging, or alternatively, cumbersome and possibly out-of-date patches.Suggested solution
Alternative
No response
Additional context
The documentation gives the impression
ResolvedConfig
is an interface. Given the docs, I wasn't sure if this should be a feature request or bug report 😅Validations
The text was updated successfully, but these errors were encountered: