feat: add $inspect.trace rune

[trueadm]

Closes #14265. This adds the $inspect.trace rune to Svelte which logs the reactive graph of the current reactive context. It must be placed in a block statement and requires a string passed as an argument which is the trace name.

[changeset-bot]

🦋 Changeset detected

Latest commit: fa941f7

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

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

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@14290

[Rich-Harris]

preview: https://svelte-dev-git-preview-svelte-14290-svelte.vercel.app/

this is an automated message

[trueadm]

Perhaps instead of having it compile to this:

$.user_effect(()=>{
return $.trace(()=>stuff, "name")
});

This PR has compiled to that output for a while now. Worth checking it out again sometime :)

I'm not sure how this will change in terms of performance (which shouldn't matter too much since its only running in dev mode), but it should result in less and simpler code.

It wouldn't make anything simpler with the new design.

[trueadm]

@Rich-Harris Feel free to apply your local changes to this PR if that's easier.

[Rich-Harris]

The 'you can put this anywhere in a BlockStatement rule' is a bit confusing, and since it compiles to a return statement it can easily result in bugs. If I mistakenly put an $inspect.trace(...) at the top level of my component, it'll tell me to put it in a block, but if I do that the component doesn't do anything because a return is inserted.

Similarly if I have a trace inside a block inside a function, everything below the block is ignored because of the early return. (The messaging if the function is called outside an effect is also a little confusing — it says there are no reactive dependencies but I can see them! Not sure how best to resolve.)

So I think the placement rule should be that $inspect.trace must be in a function block, and must be the first statement (not strictly necessary, but strong conventions are good and helpful — eliminates any ambiguity about what happens if something in the function is before or after the trace).

If we do that, I'd love it if we can get rid of the label argument, or at least make it optional — we can just use the function name, or $effect if it's the anonymous callback passed to $effect, and provide the location of the function. In rare cases there'll be no name that the compiler can determine, but the location should be sufficient. This feels way nicer than having to provide a label for something I'm probably only adding temporarily for debugging purposes.

Also: why is this showing no reactive dependencies inside the effect?

[trueadm]

So I think the placement rule should be that $inspect.trace must be in a function block

I agree, I've changed it so it has to be in a function. I didn't want to limit it to be the first entry as that can cause issues inside class constructors etc.

If we do that, I'd love it if we can get rid of the label argument, or at least make it optional — we can just use the function name, or $effect if it's the anonymous callback passed to $effect, and provide the location of the function. In rare cases there'll be no name that the compiler can determine, but the location should be sufficient. This feels way nicer than having to provide a label for something I'm probably only adding temporarily for debugging purposes.

It literally used to do exactly this, but I found it was just not useful at all. You mostly put it in effects, so it would just log $effect as the name each time and it didn't really help any finding it. I find an explicit name is far clearer, even if it's a bit less nicer than having it automagically work. Maybe the location is enough? If I can time tonight I can take a stab at it unless you do it before.

Also: why is this showing no reactive dependencies inside the effect?

Odd, it works for me locally, but not on the REPL?!

[Rich-Harris]

issues inside class constructors etc

Can you elaborate? It should be fine as long as you're not using this in the label, no?

[trueadm]

issues inside class constructors etc

Can you elaborate? It should be fine as long as you're not using this in the label, no?

They can't even use this in the label on reflection, it has to be a literal only, so ignore me!