False positive `ownership_invalid_binding`?

[huntabyte]

Describe the bug

I'm getting the following message, telling me to consider bind: between the two components. However, I am, in fact, binding between the two.

Reproduction

https://svelte.dev/playground/c27c1016f1f2423489568d9fb2271921?version=5.2.5

Logs

[svelte] ownership_invalid_bindingsrc/lib/calendar-with-select.svelte passed a value to node_modules/.pnpm/bits-ui@1.0.0-next.17_svelte@5.0.0-next.265/node_modules/bits-ui/dist/bits/calendar/components/calendar.svelte with `bind:`, but the value is owned by node_modules/.pnpm/bits-ui@1.0.0-next.17_svelte@5.0.0-next.265/node_modules/bits-ui/dist/bits/calendar/components/calendar.svelte. Consider creating a binding between node_modules/.pnpm/bits-ui@1.0.0-next.17_svelte@5.0.0-next.265/node_modules/bits-ui/dist/bits/calendar/components/calendar.svelte and src/lib/calendar-with-select.svelte

System Info

System:
    OS: macOS 15.0
    CPU: (12) arm64 Apple M2 Max
    Memory: 92.23 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.15.1 - ~/.nvm/versions/node/v20.15.1/bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v20.15.1/bin/npm
    pnpm: 9.6.0 - ~/Library/pnpm/pnpm
    bun: 1.0.25 - ~/.bun/bin/bun
  Browsers:
    Edge: 129.0.2792.89
    Safari: 18.0
  npmPackages:
    svelte: ^5.0.0-next.1 => 5.0.0-next.265

Severity

annoyance

[paoloricciuti]

Cloning the repo locally i can't seem to reproduce...what are the reproduction steps?

[someone2080]

This one is probably a duplicate of 13423

[someone2080]

So, I was able to reproduce it, but I'm not sure if it's the same reproduction as in this issue.

Here's a REPL

This happens when state is stored in a separate file from where it was declared/instantiated. I hope REPL will make it clear enough.

I wonder if it's actually a 'legit' svelte coding pattern...

[huntabyte]

Thanks for the REPL repro @someone2080 ! That's exactly when it appears to be happening when it shouldn't.

[huntabyte]

Hey team, are there any plans to allow users to shut some of these warnings up?

I understand they only run during DEV, but they can still be quite annoying when they don't impact the functionality. I know we can ignore the compiler warnings via the svelte.config.js, but I don't see a way to ignore these runtime logs.

[coryvirok]

So, I was able to reproduce it, but I'm not sure if it's the same reproduction as in this issue.

Here's a REPL

This happens when state is stored in a separate file from where it was declared/instantiated. I hope REPL will make it clear enough.

I wonder if it's actually a 'legit' svelte coding pattern...

Isn't one of the intended benefits of Svelte 5 runes that you can store state in any non-svelte component and use it elsewhere? If this isn't the intended behavior, what would be the correct way to distribute components that take state as props and modify them?

[someone2080]

@coryvirok Yes, you are right. I'm using this method, too. Runes in this mode are very powerful; they remind me of SwiftUI state management. The issue here is that this also opened a rabbit hole.

I'm not a JS expert, but this warning was meant to prevent us from doing crazy things like in this REPL, we can do this thanks to the fact that JS objects are passed by reference.

Now, Svelte team has to find a way to track down where and how this Rune was declared and issue a valid warning, which to me looks like a huge lift.

I wonder if it's possible to remove this restriction altogether and use $bindable only for simple types if necessary (kinda crazy idea though).

[kpwelsh]

@someone2080

I am seeing the same issue with what I think is a reasonable design pattern. I have 2 relevant components: 1 that produces something and 1 that modifies it.
Here are two slightly different repros:

• https://svelte.dev/playground/96d3b8ee3b6945da90b9f622903ecf5c?version=5.14.1
• https://svelte.dev/playground/2b080240491f4aa892bb8c9ee87c4170?version=5.14.1

I thought the "svelte" way to do this would be to bind variables through all of the components. I should be able to fix this with some callbacks or a moderate restructure of the data, but it seemed to me like the bind solution should work.

Edit:
Here is a repro where all of the definitions are located in the same file: https://svelte.dev/playground/8787f944e5d54146b4f9d65999ac089f?version=5.14.2.

Its not clear to me how to have this kind of behavior without seeing this warning.

[someone2080]

@kpwelsh Yeah, that looks pretty reasonable. It's a false positive.
Regarding callbacks, I use them on a regular basis instead of bindings, and for state management, I use controllers(MVVM/MVC) in the form of classes (in .svelte.ts), so I don't have problems with this warning anymore.

[krabodyan]

i am using Tauri and getting this bug even when using this example from svelte playground. For some reason, there is no this warnings in firefox 134.0 and chromium 131.0.