Reorder the type parameters of `derived`

[JeanJPNM]

Describe the problem

When declaring a derived store that has null as the initial value and has two or more stores as dependencies, I can't specify
the type that the derived store contains without first having so specify the type of the dependency array, which is somewhat frustrating.

// ideal situation (does not currently work)
// the type of the the store's value is `DerivedData | null`
// and the type of the dependecies is inferred
const myData = derived<DerivedData | null>([a, b, c], ([$a, $b, $c], set) => {
  if(!$a || !$b || !$c) {
    set(null);
    return;
  }
  const { data, dispose } = generateData($a, $b, $c);
  set(data);
  return dispose;
});

// reality

// one way to work around the problem
// manually typing the `set` parameter will yield the same result, but it's more verbose
const myData = derived([a, b, c], ([$a, $b, $c], set: (value: DerivedData | null) => void) => {
  if(!$a || !$b || !$c) {
    set(null);
    return;
  }
  const { data, dispose } = generateData($a, $b, $c);
  set(data);
  return dispose;
});

// another workaround
// like before, it yields the same result, but it's also more verbose than it should be
const deps = [a, b, c] as const
const myData = derived<typeof deps, DerivedData | null>(deps, ([$a, $b, $c], set) => {
  if(!$a || !$b || !$c) {
    set(null);
    return;
  }
  const { data, dispose } = generateData($a, $b, $c);
  set(data);
  return dispose;
});

Describe the proposed solution

Swapping the order of the generic parameters of the derived function would solve the problem.

svelte/packages/svelte/src/runtime/store/index.js

Lines 124 to 132 in f4c4d99

	/**
	* @template {import('./private.js').Stores} S
	* @template T
	* @param {S} stores
	* @param {Function} fn
	* @param {T} [initial_value]
	* @returns {import('./public.js').Readable<T>}
	*/
	export function derived(stores, fn, initial_value) {

Alternatives considered

The alternatives were listed above.

Importance

would make my life easier

[gtm-nayan]

This would be a breaking change, but even if we swapped the order I don't think it would help because you can't just omit the second parameter to let it be inferred. Probably blocked by microsoft/TypeScript#26349

[Rich-Harris]

Since $state(...) in Svelte 5 supersedes stores, we're very unlikely to make any changes to store APIs, so I'll close this

[harrisi]

Sorry, does this mean stores are effectively deprecated? If they're not being updated and are replaced by $state, it sure seems that way.

Or are they just considered stable and not being removed, but not being updated? I don't know why they'd need to stay, but the docs say they're staying so I just wanted to clear that up.

[dummdidumm]

Stable, not deprecated, and we're waiting on how things turn out (how much store usage declines etc)