Bug: `props` passed into Svelte component should not be converted to $state, causes problems

[KieranP]

Copied from vitest-community/vitest-browser-svelte#19 because the issue exists here too

Currently, this plugin is converting props passed into the render function into a $state:

svelte-testing-library/src/core/modern.svelte.js

Line 26 in 9517f83

const props = $state(options.props ?? {})

However, this is not desirable behavior and leads to things working in the browser but failing with this plugin.

Consider the following:

Parent.svelte:

<script>
	import Child from './Child.svelte'
	
	let defaultProps = {
		title: '',
		body: ''
	}
</script>

<Child {defaultProps} />

Child.svelte

<script>
	const { defaultProps } = $props()

	console.log(defaultProps)
	
	function clone() {
		console.log(structuredClone(defaultProps))
	}
</script>

<button onclick={clone}>
	Clone
</button>

In the browser, this works fine. defaultProps is passed unchanged into Child, and clicking Clone button works as expected.

However, consider this in plugin:

import { render } from '@testing-library/svelte'
import Child from './Child.svelte'

describe('compatibility test', () => {
  let defaultProps = {
    title: '',
    body: ''
  }

  it('successfully clones object', () => {
    const { screen } = render(Child, {
      ...defaultProps
    })

    const btn = screen.findByRole('button')
    await btn.click()
  })
})

This fails, because defaultProps passed into render is converted to $state. That $state is then passed into structuredClone, and that fails with:

DataCloneError: Failed to execute 'structuredClone' on 'Window': [object] could not be cloned

In short, this plugins conversion of props into $state is causing many failures that do not happen when actually run in a browser.

[mcous]

Hey @KieranP! Unfortunately, the internal $state rune is what allows the rerender method to work, because it's the only way to update props using Svelte's client-side API. svelte@5 replaced the explicit $set method to update props with the instrutions to use a $state rune, instead: https://svelte.dev/docs/svelte/legacy-component-api#$set

const { rerender } = render(Child, { message: 'hello' });

expect(screen.getByText('hello')).toBeInTheDocument();

await rerender({ message: 'goodbye' });

expect(screen.getByText('goodbye')).toBeInTheDocument();

The rerender method is common in the component test suites I've interacted with, leaving us in a bit of a tight spot with the Svelte 5 update. We had to either:

1. Drop the rerender method, forcing users to re-write their tests as .svelte.test.ts and create their own props rune
2. Internally create a $state rune for props and use it to drive rerender functionality, which is a little awkward but works for the majority of cases

I think (2) was the right choice at the time to ensure folks could have a smooth update to Svelte 5. In my head, I was planning on doing (1) whenever Svelte v6 dropped and a breaking change on our end could be a little more palatable.

I'm not super jazzed about a breaking change to this package right this second. But I do agree that the implicit, internal $state rune is less than ideal, and I can see it causes problems in certain edge cases.

I appreciate the reproduction case you've provided - I'm gonna poke at it and see if I can come up with a non-breaking way to bypass the internal $state rune that I don't hate

[mcous]

Good news: I spoke too soon! I think there is, in fact, a way to move forward here that removes the "implicitly make every part of props a deeply reactive proxy" behavior while preserving rerender functionality.

It's a bit... involved though, involving an internal $state.raw rune along with our own Proxy. Given that Svelte's "invisible" use of Proxies is what got us into this mess, it definitely re-affirms my belief that at some point, this internal $state run should go away in the next major version

Regardless, I'll start prepping a fix

[github-actions]

🎉 This issue has been resolved in version 5.2.9 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[KieranP]

@mcous Thank you for the fix. Interesting solution. Nice work.