Compatibility for libraries publishing compiled components

[SystemParadox]

I am looking to get a bit more information about compatibility guarantees when publishing a library of svelte components.

This isn't really stated anywhere in the svelte docs, but sveltekit has this https://svelte.dev/docs/kit/packaging, and there are a few related issues from way back in the svelte 1 days along similar lines. It appears the current recommendation is that libraries publish svelte components as svelte source code (preprocessed, but still .svelte source code).

We have quite a large library (currently internal usage only, but a library none the less) of svelte components. We were publishing it as svelte source initially, but:

• We had various issues with making this work, particularly around things like tsconfig/path aliases and dealing with svelte source vs other code files which were built
• Having to build these significantly increased the time it takes to start the app in dev mode or build for prod

So because of this we changed to publish the built versions of the components instead, which simplified and sped things up significantly (except for the issue with trying to generate .d.ts files, but we'll ignore that here!).

Since then, our library and all derived apps have been pinned to svelte 3.55.1 to avoid compatibility issues. Now that svelte5 is here we would like to upgrade everything.

However, we really need to know what is the svelte team's policy regarding compatibility for compiled svelte components?

I fully expect that jumping major version is not supported, which is fair enough. However, with svelte 5 still under such rapid development, it seems very likely that we'll want to do fairly regular minor upgrades. Can we rely on these being forwards or backwards compatible so that we can upgrade our library or apps independently?

If we have to do these in a specific order so that the lib always has to be upgraded first or vice-versa that's fine, I just really want to avoid having to keep upgrading everything at exactly the same time.

[Ocean-OS]

I don't think you can decompile an old Svelte component, unless you try to do it by hand (and you'd have to know a lot about Svelte's old internals). Since the structure of compiled Svelte components changed dramatically in v5, it'd be very difficult if not impossible to make an old compiled conponent work in Svelte 5.

[SystemParadox]

I think you've misunderstood what I'm asking.

[dominikg]

However, we really need to know what is the svelte team's policy regarding compatibility for compiled svelte components?

none, you are responsible for ensuring precompiled component output is paired with the exact compiler/runtime version. Even patch releases of svelte can make incompatible changes to the output, it is expected that all .svelte code is compiled by the same version and paired with a runtime for that version (taken care of by sveltekit and if you import source .svelte files from libraries as packaged with svelte-package.)

[dominikg]

we do not document or recommend shipping precompiled components for this reason.

[SystemParadox]

It might be helpful to clearly state this somewhere in the documentation (the svelte docs, not just sveltekit), that there are no compatibility guarantees for compiled output, even between patch versions.

[SystemParadox]

Thanks for the response. Is this likely to change at any point?

[dominikg]

technically svelte5 new client runtime approach would make it a bit easier to define a semver-stable runtime api, But i would not hold my breath on it. the earliest this could happen would be svelte6 and it would be a big change from the current approach that gives us more flexibility to change things around as needed without having to worry about it.

[paoloricciuti]

Not to mention that pre compiling means that you forgo every bug fix we ship to the compiler itself.