New `state_referenced_locally` warnings with svelte `5.45.3`

[ahkelly]

Describe the bug

When upgrading from svelte 5.45.2 to 5.45.3 a rash of new state_referenced_locally warnings pollute the terminal in dev and when attempting to npm run build. any of my existing apps with no build or dev warnings or errors now get spammed with mega volumes of anxiety inducing warnings.

Reverting to 5.45.2 for now resolves the issue.

Reproduction

Simply do a fresh install which as of now will use the "buggy" 5.45.3

npx sv create test_app_svelte_5453
SvelteKit minimal
cd create test_app_svelte_5453
npm run dev

you will see the warnings

 [vite-plugin-svelte] .svelte-kit/generated/root.svelte:11:27 This reference only captures the initial value of `stores`. Did you mean to reference it inside a closure instead?

Under npm run build you will get similar warnings (though the build will complete)

 [vite-plugin-svelte] .svelte-kit/generated/root.svelte:17:18 This reference only captures the initial value of `page`. Did you mean to reference it inside a closure instead?
https://svelte.dev/e/state_referenced_locally
15:     $effect.pre(() => stores.page.set(page));
16:   } else {
17:     stores.page.set(page);
                            ^
18:   }
19:   $effect(() => {

Logs

System Info

Linux Ubuntu 22, Node 24, npm 11.6.2

Severity

blocking an upgrade

[bigmac44]

Seems to be from this change which I can understand the reasons for.
#17266

For what it's worth, giving AI the output of npm run check (svelte-check) and asking it to add
// svelte-ignore state_referenced_locally to any lines with the warning worked reasonably well.

[Conduitry]

Warning users when they're not going to be reacting to changing prop values makes sense to me. I agree that shouldn't be changed back. What should be fixed, though, is that internal components within SvelteKit are now triggering this warning.

[ahkelly]

I am hopeful at some point I will see the virtue in this "update" but for now it is just super naff and unnecessary. If I make the following declaration

let { data } = $props();
const temp_order_object = data?.temp_order_object?.recordset[0] ?? {};

The simple fact I have declared the variable with const should make it reasonably clear I know this is not going to change, I don't want it to, I did not use $state() so leave me alone to wallow in my own supposed incorrectness. I hear the advice to litter my code with // svelte-ignore state_referenced_locally but really ?? Shouldn't the complier leave me alone if I have zero expectation of the value being reactive?

A perfectly working app (with this update) is now littered with hundreds of obnoxious warnings of supposed issues that are not affecting my app at all. As I said here's looking to future me who will grasp the wisdom of this over reach.

[frederikhors]

I agree with @ahkelly and I was about to open an issue for this very reason!

Read:

• state_referenced_locally warning inconsistencies #16343
• state_referenced_locally warning inconsistencies #16343 (comment)
• state_referenced_locally warning inconsistencies #16343 (comment)

This is not very useful.

[paoloricciuti]

Declaring with const doesn't affect the state referenced locally warning:

<script>
  let { name } = $props();
  const upper = $derived(name.toUpperCase());
</script>

will react even if it's a const (it just means you can't reassign).

But also...are you sure you don't want it to be reactive? If you navigate to the same route SvelteKit will not unmount your +page.svelte component it will simply update the props...which in turn means that if you are not using deriveds, and you happen to navigate to the same route and the data is different you will have stale data.

[ahkelly]

The biggest issue is why is this a constant moving target and was not nailed down with $state() long ago I mean there was 900+ beta versions of svelte 5 before release and now two years later this is still being fleshed out. I find it really unerring that code that has run fine for more than a year gets a point update and it now throws off hundreds of warnings. This is first I have heard of wrapping this stuff like this in $derived(). That warning makes no sense to me, I am retrieving load data and displaying it, why should it have to be wrapped in a $derived(), what is being "derived" ?

[sillvva]

Here's an example using page params to demonstrate the issue that this warning is for:

https://stackblitz.com/edit/sveltejs-kit-template-default-ypkjzxre?file=src%2Froutes%2F[slug]%2F%2Bpage.svelte

As you change pages, the value assigned to the slug state doesn't change.

---

Another simpler example using just component props:

https://svelte.dev/playground/2d9940edea5f4669a8a0bdf960b73656?version=5.45.3

[Rich-Harris]

The biggest issue is why is this a constant moving target and was not nailed down with $state() long ago

It's called 'learning'.

The reality is that almost all of the time, if you're using a prop's initial value, it's a bug. It may not appear buggy immediately — perhaps the prop doesn't change when you're testing the app, or maybe the users of the component in question are only passing static values to it at the moment — but the bug is there, waiting to bite you.

In fact a side-project of mine at the moment involves an inherited codebase that has accidentally become infested with these bugs. They would never have gained a foothold if we'd had this warning earlier.

I don't know exactly what your code is meant to do, but this definitely looks suspect to me — this looks like the sort of value that will change over time, and if temp_order_object doesn't change with it then things are likely to get out of sync:

let { data } = $props();
const temp_order_object = data?.temp_order_object?.recordset[0] ?? {};

[Tihomir971]

What to do with raw state. I get same warnings.

let { items } = $props()
let filteredOptions = $state.raw(items);

[yaman-cruise]

I struggle to fix deep state because $derived doesn't support it. I have the following code

let assets = $state<(AssetType & { masterId?: number })[]>(nativeTemplate?.assets ?? [])

How do I change this? I could introduce $effect and there wouldn't be a bug anymore:

let assets = $state<(AssetType & { masterId?: number })[]>(nativeTemplate?.assets ?? [])
$effect(() => {
  assets = nativeTemplate?.assets ?? []
})

But this still throws the error.

[Tihomir971]

I struggle to fix deep state because $derived doesn't support it. I have the following code

let assets = $state<string[]>(nativeTemplate?.assets ?? [])
How do I change this? I could introduce $effect and there wouldn't be a bug anymore:

let assets = $state<string[]>(nativeTemplate?.assets ?? [])
$effect(() => {
assets = nativeTemplate?.assets ?? []
})
But this still throws the error.

Did you try:

let assets = $derived<string[]>(nativeTemplate?.assets ?? [])

[brunnerh]

For a deep $derived you can usually do this:

let assets = $derived.by(() => {
  const asState: string[] = $state(nativeTemplate?.assets ?? []);
  return asState;
});

There was some discussion around allowing $state directly in $derived but I don't know the status of that.