Errors when trying to use components compiled with previous Svelte versions

[nsaunders]

It looks like new versions of Svelte are breaking compatibility with components compiled with previous versions of Svelte. For example, I have created a component ScratchComponent that works fine in the REPL with v1.18.1 but doesn't work with v1.19.1 and also doesn't work with the latest version. Thoughts?

[PaulBGD]

Oh yikes, that shouldn't happen. I wonder what commit caused this.

[Conduitry]

It looks like this happened as part of a refactoring while transitions were being added. _renderHooks went from being an array of objects with a fn key on them that was the function to call, to being an array of the functions themselves.

Fixing this seems like it would have to involve adding extra code for everybody, unfortunately, whether they need this private API stability or not. The _flush shared helper function would have to be able to handle either kind of array.

[nsaunders]

What's done is done. We have updated our component library to use the latest Svelte version; problem solved...mostly. (We have broken compatibility with 1.18.1 client apps, but they just need to upgrade as well.)

But I think going forward that this use case needs more attention. Maybe my team is the first to develop a UI component framework with Svelte, but I'm sure that when Svelte gains more traction a lot of companies will be trying to do this.

[Rich-Harris]

I suppose the lesson here is that anything that is used for inter-component communication is technically part of the public API (and thus subject to semver) even if it has an underscore prefix. Perhaps we should add some tests around this stuff.

[Rich-Harris]

I've put together a proposal that attempts to address this situation a bit more fully: #604. Would welcome feedback, particularly from @therealnicksaunders as you might have insight into whether this would work in practice, having already developed a component framework.

[nsaunders]

I have an idea: How about we just log a warning (or even an error) at runtime when a component nests another component that was compiled with a different version of Svelte?

Pros:

• Easy to implement?
• Provides an actionable message rather than just (for example) "this._renderHooks.pop(...) is not a function".
• No need for the client to compile Svelte components installed via NPM.

Cons:

• Possibly a bit too restrictive in the sense that we may surface an error/warning when the components are, in fact, compatible despite being compiled with different Svelte versions. (I don't think this is a big deal, though, as the upgrade path from one Svelte version to the next has been trivial so far compared to, say, Angular 2+. But, if deemed necessary, perhaps the Svelte compiler could just provide an option to disable the error/warning message.)

[Rich-Harris]

That's a possibility. It would mean adding a version string to every component, which is wasted bytes in the majority of scenarios.

I'd just reiterate that with regard to...

No need for the client to compile Svelte components installed via NPM

...I think Svelte apps should be compiling Svelte components — it's not just about avoiding compatibility headaches, but about ensuring that code is shared as far as possible, since that means apps that start up quicker (because there's less code to download and parse) and run quicker (because functions are more likely to be optimised quickly). It's just hard to do that at the moment because we don't have pkg.svelte. It's not equivalent to installing e.g. a TypeScript project and having to run tsc on your dependencies, because in this case there's no additional setup work for the developer.

[Conduitry]

There is a pkg.svelte field now, so I think this can be closed. Can re-open if someone disagrees.