fix: re-run non-render-bound deriveds on the server

[Rich-Harris]

I tried to bring #14977 up-to-date but it's slipped too far. Also, I wanted to try a slightly different approach.

In this PR, deriveds are memoized if they're created during render — in other words if you have something like this...

<script>
  let thing = $derived(expensivelyComputeThing());
</script>

...thing will only be computed once. This seems correct since the inputs should never change during render.

For deriveds created outside render, we re-run the derived each time it is accessed, which fixes #14954. This way, there's still some overhead compared to how deriveds work in the browser (where they only recompute when their dependencies have changed), but only in the rare places where it is necessary.

There is one wrinkle: writable deriveds. On main these are just regular old variables, which means they can be written to during render. This PR currently preserves that behaviour, but I'm not sure it's desirable. It prevents the values of non-render-bound deriveds from ever updating, and makes no sense in the context of render-bound deriveds since they shouldn't be changing during render anyway. So my preference would be to disallow writes to deriveds on the server, but I'm not sure if we would need to consider that a breaking change.

Draft because of that question, and also because I think we might be able to tidy up some stuff around class fields.

• figure out if we can delete some existing code around derived class fields
• figure out what to do about writable deriveds
• add a test

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 9124349

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

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

[github-actions]

Playground

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

[dummdidumm]

Draft because of that question

It's no longer in draft, so what was the conclusion?

[dummdidumm]

so this basically means that the value will run over and over on the server? FWIW I think that's fine

[Rich-Harris]

exactly, yeah. the alternative would basically be to implement full reactivity, which seems extravagant and unnecessary

[Rich-Harris]

what was the conclusion?

that the path of least resistance was to maintain the existing behaviour, even though you can break things if you try hard enough (by writing to a derived that should later be updated via its dependencies)