Closed Fryuni closed 10 months ago
Hi, Thanks for the notice! Somehow it's not reproducing on my end in the Astro sample: https://github.com/elringus/imgit/blob/main/samples/astro/astro.config.mts, though I'd like to solve this anyway. We can't directly import Vite's plugin type, as it's not a dependency of the plugin. And we can't use any
, as it violates codefactor linting. So the only solution I guess would be declaring compatible VitePlugin
type. Do you happen to know the min. required type structure that will satisfy Astro requirements?
I can send a PR with the subtype being used later today 😄
Would be great, thank you!
Took me more than I expected to get to this, but it turns out you already have the vite
plugin properly typed. Just had to refer to it, so here it is:
The type declared for the Astro plugin specifies
unknown[]
for Vite's plugin config. This is incompatible with the realAstroIntegration
type from astro.Print of the error formatted
![image](https://github.com/elringus/imgit/assets/11063910/32bed9b2-9ae2-4eb6-b27b-331121a4d9a4)https://github.com/elringus/imgit/blob/e449e6fd12ee89884a23d950fcfd10ef51061e71/src/plugin/astro.ts#L11
That
plugins: unknown[]
is inside a function parameter, making the type ofupdateConfig
contravariant over it. But theupdateConfig
field is itself part of a function parameter, meaning thatastro:config:setup
and by extensionAstroIntegration
contravariant overupdateConfig
. Transitively,AstroIntegration
is covariant over theplugins
field.This means that assigning this
AstroIntegration
type over Astro's actual type would requireunknown
to be assignable to Vite'sPluginOption
, but of courseunknown
is not assignable to anything except itself by definition (since it is a top type).The field should either:
PluginOption
PluginOptions
, possibly with only the used propertiesany
, which is both a top and bottom type and accepts any assignment in both directions