Explicitly set store type is incorrect when the store initialized without argument

[shadow-identity]

Describe the bug

svelte-check and typing system (both JSDoc and TS) does not report an error when a typed non-undefined store initialized without initial value.
It does not produce any typing error, although in this case the store value is undefined and does not meet the original expected type.
It leads to runtime errors, which are hard to predict, especially for people not familiar with this bug.

Reproduction

With JSDoc:

/** @type {SvelteStore<string>} */
const myStore = writable()  // No error

/** @type {string} */
const myString = $myStore // No error
console.assert(typeof myString === 'string')  // It fails!

Same applies to TypeScript:

const myStore = writable<string>()
const myString: string = $myStore

I expect a type error when initializing the store without arguments.
Or, at least, to expand the initial type with undefined, so $myStore will be typed as string | undefined, but this could be confusing.

Logs

No response

System Info

Happens on both Svelte 4 and 5.

Severity

annoyance

[AndyCobb]

👍
I expect the type system to warn me that the value might be undefined. This is a very common pattern and easy to miss, and can easily lead to runtime errors.

const myStore = writable<string>();
$myStore.length; // no warning, but will error

I agree that the ideal fix would be for a type error when initializing to undefined when the type T doesn't allow it. Reporting that the value is type T | undefined would be confusing since it doesn't match the requested type, but is actually correct for the current implementation.