Closed mcous closed 7 months ago
Is there any consumer emulation as part of the CI flow?
I've setup a svelte5 project (with npx create svelte@latest
) and chosen vitest
support, then changed to this PR's commit:
+ @testing-library/svelte@git+ssh://github.com/mcous/svelte-testing-library#150335aac28f071710ca5771d4dc2a4f7363633c
1 package installed [1.56s]
...but running a simple component test still fails to render :disappointed: I had hoped for more success seeing all the jsdom checks passing here, but I'm still seeing the same error as the latest release:
Instantiating a component with `new` is no longer valid in Svelte 5.
It'll soon be in a next
release. I've just cut the very first testing of next
this morning with some other changes, and I'll try to add in the v5 support in that branch later on. Hold tight, I'll try to report on it before the end of the day.
@RobinKnipe that smells like a dependency install issue, you might want to check if you have duplicate versions installed with npm why @testing-library/svelte
(if I'm remembering that command properly).
Like @yanick said, you'll probably have a happier time if you wait for the prerelease version in npm. I've never messed around with installing this library via git so I don't really know what pitfalls and limitations exist, especially coming if it's coming from a fork rather than upstream
If you're curious what our CI does, check out release.yml in the workflows folder; it's fairly straightforward.
If it helps; some partial success in this test project. Noddy unit tests created for the 2 components from the default "create svelte" setup (one working, one failing).
This is using the changes in this PR:
svelte5$ npm why @testing-library/svelte
@testing-library/svelte@0.0.0-semantically-released dev
node_modules/@testing-library/svelte
dev @testing-library/svelte@"git+ssh://github.com/mcous/svelte-testing-library#150335aac28f071710ca5771d4dc2a4f7363633c" from the root project
@RobinKnipe your example repo has three problems, all interacting/hiding each other, that are causing that <Header>
failure. All three issues are about how to test SvelteKit apps, not Svelte v5. The exact same failure happens if you switch your repo to Svelte 4.
$page
store will be empty in unit tests, so your test crashes on:
TypeError: Cannot read properties of undefined (reading 'pathname')
❯ Object.hydrate [as h] src/routes/Header.svelte:19:32
17| </svg>
18| <ul>
19| <li aria-current={$page.url.pathname === '/' ? 'page' : undefined}>
| ^
20| <a href="/">Home</a>
21| </li>
Since these are not issues with this library nor Svelte v5, if you have any additional questions, please open a separate discussion if you need help testing a SvelteKit app
Basing on 'next', and I'm going to push the conflict resolutions in 2 minutes.
@mcous You good with me merging this bad boy into next and seeing if it triggers our first next-type release to npm?
@yanick oh boy 😬, no time like the present
The only thing giving me pause is that our next
branch is not configured as a prerelease
in release.yml
. So I think merging may bump to 5.0.0
proper and release it on the next
tag.
Not sure what your desires are on 5.0.0
vs 5.0.0-next.0
(or whatever). Either way I'm happy with what you choose! I'm fairly confident with this PR given the test matrix and the low risk to harming Svelte v4 support
The only thing giving me pause is that our
next
branch is not configured as aprerelease
inrelease.yml
. So I think merging may bump to5.0.0
proper and release it on thenext
tag.
Oh yeah, you're right. next
and main
are regular releases, and alpha
and beta
branches are prereleases.
Not sure what your desires are on
5.0.0
vs5.0.0-next.0
(or whatever). Either way I'm happy with what you choose! I'm fairly confident with this PR given the test matrix and the low risk to harming Svelte v4 support
Hmmm, it's true that with the test suite, the chances that we'll utterly bugger up everything are slim (and yes, I just jinxed us by saying that). But today is a beautiful day to di-- I mean, deploy, so let's Leeroy Jenkins this puppy out and see what happens. >.>
:tada: This PR is included in version 4.2.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Hey, cool! Looks like it missed the breaking fix!
for the rerender
changes, but I'd like to land a few more pedantically breaking changes into next
anyway (see #312 and #313) so we'll see what happens
@mcous ah it's SvelteKit related!? Ok, I'll try and refine my testing to Svelte only examples. Thanks!
Overview
This PR is an alternative approach to #284 (CC @yanick) that adds experimental support for
svelte@next
without breaking support for Svelte v3 nor v4. I think adding support for the prerelease version of Svelte v5 as soon as possible will be a really helpful move for everyone trying to migrate - myself very much included.This PR requires the cleanup work I did in #314. Please see https://github.com/mcous/svelte-testing-library/pull/1 in my fork for the incremental diff from #314 to here. This PR is ready for review, but #314 should merge first
Issues encountered
onMount
andonDestroy
are attached and called asynchronouslyonMount
noronDestroy
will be calledact()
s to get passing againanchor
option has been removedElement.animate
is required to run transitionshappy-dom
is pretty broken, probably a Svelte issueWork after this PR
onMount
andonDestroy
are called, we'll need to makerender
async so it can calltick()
after render, which will be a breaking change