Recent releases often introduce bugs

[falco467]

We have been using Svelter for several years up until now. We usually install patch releases automatically in our build process. This was not a problem for many years, since I seldom encountered any bugs with an update from e.g. X.X.23 to X.X.24

I have now encountered breaking bugs in recent patch releases for the third time in the last few months.

One update broke select boxes when the list of options changes. This was immediately visible, because select boxes just became blank after choosing an option in many of our applications.. A fix is still pending review.
#17148

Another update stopped layerchart from working by breaking the build completely and had to be fixed by a workaround from layerchart devs.
#17750

The most recent update can break the invariant of if-blocks inside of snippets in components. I get null-pointer exceptions inside a svelte if-block which checks if the variable is null.
#17866

All this gives the impression that something changed in how svelte is developed. I get the feeling new features are shipped eagerly and not tested sufficiently. It might have to do with LLM-assisted development, which can quickly generate code satisfying all tests, but subtly wrong because it lacks the insight of a seasoned developer.

Do you share this impression?

[gterras]

Anyone using Svelte in a demanding context feels the same unfortunately. Posts like yours now pop up on a weekly basis. The sad truth is that Svelte patch updates put a project more at risk than your regular lib major updates, and it doesn't seem to get better as days pass and worked is poured into it (see #17868 just a few hours ago).

I have been using Svelte professionally and daily for almost 8 years and built an entire ecosystem on it, and can confirm the current situation is an all-time low.

All this gives the impression that something changed in how svelte is developed.

Quite the opposite, the context changed but the development methods stayed the same, hence the problem.

The biggest concern is that the team doesn't seem to see this as an actual problem to solve, so it probably won't be solved until then. See my comment on a similar thread that didn't get any other official comment than "we are doing our best", which I don't doubt, but is not the point, the point being "how to solve this problem" instead of doing the same thing again and expecting different results.

I don't think the team quite understands how much it hurts when your users, your coworkers, your bosses starts legitimately questioning the choices you fought for or your ability to guarantee a working product. In the lack of official acknowledgement, strategy or discussion about it, the solution seems to be "just one more commit bro I swear". The release cycle really reveals this mindset : it's not uncommon to get 3 patch releases in a single day that all leads to some kind of regression. This is definitely not suitable for a professional usage.

It might have to do with LLM-assisted development

It started before that, with the new reactivity system. My theory is that while this system was designed to reduced the overhead in some complex reactivity situations, this complexity didn't disappear, it was simply moved to the codebase. So now instead of letting the users decide whether or not they want this complexity in their components it weights unconditionally on everyone, maintainers included. Svelte5 was meant to be fit for more complex apps, dropping the legendary simplicity of Svelte4. Turns out it now does not satisfy simple cases nor complex ones. I'm quite sad to say this but as of right now, I wouldn't recommend Svelte5 to anyone.

As you said, recent introduction of LLMs-generated code like it's a small detail will most probably subtly but surely make things worse overtime, because that's the conclusion most people using them in complex systems already came to. The team seems unaware of this issue, see this thread where I try to expose the point. LLMs could still be very useful for methodically generating test suites, but this requires the acknowledgement of the problem first.

[falco467]

I have the feeling a turning point was the introduction of async mode (top level await) - which was a giant change in the ECO-System, which would probably have warranted a major version switch, since it changed the complete reactivity model inside out.
It seems the last few months we are actually using svelte@next instead of a stable branch, since the whole effort was prematurely pushed to the main branch instead of a beta/evaluation branch.

[falco467]

Maybe Svelte development could orient itself by looking at the Go Development process? Introducing new major features as experiments first, tracking how many people activate the experimental flag in their code-base and only pushing the feature from experimental to default after enough real live adoption and resilience.