This is what https://svelte-5-preview.vercel.app/docs/runes#$state-snapshot is for. I don't know whether it makes sense to patch structuredClone in dev to print a warning about this. There's going to be a never-ending list of libraries and APIs that don't expect proxies.

I'm aware of that, but there is zero indication of a problem in code editor.

Svelte lies to TypeScript that $state returns the value it holds, but in reality it returns the value wrapped in a proxy. New developers won't be aware of this, and tools like TypeScript will never know. Developer can easily introduce a bug in their code and the tools that suppose to catch it are unable to because they are being lied to.

I don't know what will Svelte team do regarding this issue, but this definitely should be fixed one way or another. I would suggest a fix but I am by no means qualified to talk about tool design (especially given the scale of Svelte).

I would really love the addition of Boxed<T>.

We can probably monkey patch structuredClone in DEV and warn to use $state.snapshot if encountering a Svelte proxied object. However, that can wait till 5.x as this isn't urgent.

Just one more thing I wanna say here, If a function returns an object that is something like:

{
  name: string
}

Just by seeing the type, you have no idea if this is reactive or not, You have no idea that if you do, const somehting = $derived(x.name + " something"), this is actually reactive or not. In most cases you have to check the implementation(or docs) to see if its a signal or just a normal property/getter.

Just one more thing I wanna say here, If a function returns an object that is something like:

{
  name: string
}

Just by seeing the type, you have no idea if this is reactive or not, You have no idea that if you do, const somehting = $derived(x.name + " something"), this is actually reactive or not. In most cases you have to check the implementation(or docs) to see if its a signal or just a normal property/getter.

Not much we can do about this with today's tooling. The same issue applies with any proxy reactivity library.

If the return type of signals were Boxed<T>, which is just an alias for T wouldn't it help (in type level I have some idea what I'm dealing with)? Also it wouldn't break current code if I'm correct.

@FoHoOV No, that wouldn't help at all. Boxing things doesn't solve anything – it just moves the problem to another area and in this case doesn't solve the problem of proxies. Unless you expected each property of the object/array to also be boxed – but that's terrible ergonomics.

I must be using the wrong terms here, Boxed<T> is just an alias for T. They are basically the same but have different semantics. All siganls should be returning Boxed<T> (again just an alias for T ie Boxed<T> = T)

You would need to add a property or symbol to the type, otherwise the wrapper type gets erased. And if you do that, you are no longer allowed to assign to the variable, because the added property will be missing from the new value.

const stateKey = Symbol('state-key');
type StateProxy<T> = T & { [stateKey]: unknown };

declare function $state(value: number): number;
declare function $state(value: string): string;
// ...
declare function $state<T>(value: T): StateProxy<T>;

let a = $state(5); // number
let b = $state({ value: 3 }); // StateProxy<{ value: number }>

b = { value: 5 }; // Error

Playground

You need to make the symbol optional { [stateKey]?: unknown } but the real problem is that you cannot rid of the marker:

let a =  $state(5); // StateProxy<number & { [stateKey]?: unknown }>
let b = a; // b will have the same reactive type while, in fact, it is static

you cannot rid of the marker

That is fine, it's a statement about the object, not the variable.
(And the type of primitives will not be affected.)

It should be recursive (it's possible) but only for POJOs. In TS, a class instance and a POJO with the same fields are the same thing, aren't they?

It should be recursive (it's possible) but only for POJOs. In TS, a class instance and a POJO with the same fields are the same thing, aren't they?

Their prototypes also have to be the same.

A mean this case which results in a wrong type