feat: $effect.pending(value) (runtime-first approach)

[dummdidumm]

This lifts the restriction of having to put this lexically inside an effect, now it can appear anywhere as long as it's called in the context of an effect or derived. We're leveraging the existing pending logic but instead of returning a number we're executing the function that was passed and return its result. We also have a map with all the current source values which is used for the duration of the execution of said function.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b92d2b0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@16926

[Rich-Harris]

If we can get this to work, that'd would be way better. Right now I'm seeing some glitchy behaviour — I suspect it's less caused by this PR than revealed by it, but either way we need to investigate.

With the other PR it's possible to get into a broken state if you spam the button enough...

Screen.Recording.2025-10-13.at.2.48.02.PM.mov

...but with this PR it seems to happen much more easily:

Screen.Recording.2025-10-13.at.2.49.45.PM.mov

[Rich-Harris]

Basically as soon as you have an $effect.pending(), with or without an argument, things start going wacky if promises resolve out of order — demo. If you uncomment the second line, things get wackier still — not sure if the same bug or a different one. Things are also wacky on main. Investigating.

[dummdidumm]

I'm somewhat confident this is the same bug that caused me to add the TODO there's something else buggy comment atop the one test assertion in #16935 - that stale batches are not reliably detected and so they just run, and then we end up in mark_effects with all sorts of weird sources and things go downhill from there - so yeah, not caused, but more revealed by this.