You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey folks, I'm noticing that the published type declarations seem to be out of date with the plugin options that are documented in the README.md.
Specifically, I'm noticing the mismatch with the hydratable option. It is not present on the Options interface, but it is kinda referenced within Options["compilerOptions"]. Additionally, generate is also missing, but declared within compilerOptions in the same way, yet the types line up when I'm using it.
I'm not sure of the right approach to this, but I would be willing to make this change and have the types match up with the public API.
My first thought was to sort of spread out the compilerOptions up one level, but that also looks like it would conflict with what the plugin is doing under the hood
Currently master is unreleased, so any use of compilerOptions is not supported until 7.0 comes out.
Before than, any 6.x branch had an incomplete set of type definitions to begin with. This PR (#126) was meant to fix that, but in order for it to work consistently, it had to ensure a minimum requirement for svelte/compiler, which was a breaking change & kickstarted the 7.0 rc
You can send in PR on the 6.x branch to manually type the old options. Or you can just throw a @ts-ignore above the unknown options 😆
Hey folks, I'm noticing that the published type declarations seem to be out of date with the plugin options that are documented in the README.md.
Specifically, I'm noticing the mismatch with the
hydratable
option. It is not present on theOptions
interface, but it is kinda referenced withinOptions["compilerOptions"]
. Additionally,generate
is also missing, but declared withincompilerOptions
in the same way, yet the types line up when I'm using it.I'm not sure of the right approach to this, but I would be willing to make this change and have the types match up with the public API.
My first thought was to sort of spread out the
compilerOptions
up one level, but that also looks like it would conflict with what the plugin is doing under the hoodAny thoughts?
Versions:
The text was updated successfully, but these errors were encountered: