Svelte 5 support

[calvo-jp]

Tho svelte 5 is backwards compatible, it would be nice if we can have a runes version of this library. I'm a huge fan. Thank you for all the effort you've put in in this lib

[pablo-abc]

Thanks for using this library! I've sadly not used Svelte for the past year or so :( been working with Vue so I haven't looked that much into how runes are used. Specially on libraries since I understand they only work on .svelte.js files?

Felte heavily relies on stores to handle state internally (even the adapters for other frameworks use observables internally)

Do you have an idea of how you'd expect a runes API to look like for Felte?

[calvo-jp]

planning to explore the codebase sometime this week. But what I currently have in mind is to replace stores with runes to align the api more to svelte 5. eg. below

<script>
let schema = $derived(z.object({ ... }));

let form = createForm({ 
  get extend() {
    return validator({schema})
  }
}) // or maybe a function that returns a config
<script>  

<form use:form.action>
  <div>
    <input type="email" name="email" />
    {#if form.errors.email?.length}
      <div>{form.errors.email[0]}</div>
    {/if}
  </div>

  <button type="submit" disabled={form.isSubmitting}>Submit</button>
</form>

[paradoxe]

Actually, the package depends on peer svelte@"^3.31.0 || ^4.0.0" which make it unusable with svelte 5. Bumping the svelte peer versions to include v5 will be much appreciated. Thanks

[calvo-jp]

Opened a PR to add ^5.0.0 to peer dependencies. Thanks!

[pablo-abc]

@calvo-jp I've merged and published your PR. I've checked the new docs and I see even <slots> are now replaced by snippets so reporter-svelte will eventually need an update as well.

---

@paradoxe the internals of Felte are quite framework agnostic and accepting runes as parameters would require mayor framework specific code (and the config object has never been anticipated to be reactive).

For the returned stores I could imagine a wrapper that creates runes for each data store, subscribes to the stores we use internally and updates the values of said runes. I'd imagine that would mean no more destructuring on the returned object to maintain reactivity, though.