Closed niemyjski closed 9 months ago
Svelte 5 doesn't export a listen
function from its internals anymore (it was something Svelte 4 internals exposed). This looks like an issue with svelte-legos
as it's depending on an internal API that no longer exists.
@trueadm that might be the case but when you say svelte 5 has 100% backwards compatibility. It sure doesn't look like it, internal api or not, it was exported to a public api surface. A shim should be there with some warnings logs
100% backwards compatible if you're using public API. Internal APIs are subject to change in every release. We can't shim the old runtime, it has completely changed how it works.
Seems like you could have at least left them in place and had empty functions / polyfills that throw what an alternative might be... Fact is they still were exported and public, people are using them these are two popular svelte libraries. who knows how many libraries are using them. Perhaps having a linter that errors would go a long way from having people use these.
I totally get it from your perspective. I'm a framework / library developer myself.
The error already tells you that there is something wrong, I don't think having an empty function that errors would make this any easier. We could maybe look into shimming a few selected high-usage internals, depending on what is commonly used across frameworks, but that's about it - and even that makes me nervous because people could think "oh ok I'm going to keep using those internal methods" and that just postpones the time of breakage a bit.
Agreed, can we also call this out on the 5.0 breaking changes and alert text saying don't use imports from this package? I'm also kind of curious why these developers would have thought it ok to take on internal package references, are these behaviors not exposed via public apis?
appearantly a lot of people do. https://github.com/search?q=svelte%2Finternal&type=code but i'm not sure how to get more explicit than naming it svelte/internal.
Maybe we can look into import maps with # refs so that svelte5 internals are truly opaque?
We do communicate that svelte5 is a complete rewrite, so there's no mistake or implication that anything internal will stay the same. Adding it to the list of breaking changes would be redundant.
redundant yes, but communication is always a good thing :)
I'd also ask why so many people are using the internal api, what is the public api possibly missing?
Describe the bug
Once I upgraded to svelte 5 preview I became unable to compile and run my website due to compile errors. They all seem to stem from the same issue and it's blocking adoptions.
Severity
blocking all usage of svelte