Open pooledge opened 1 year ago
See this comment https://github.com/microsoft/playwright/issues/16787#issuecomment-1230857867 We may add better support once SvelteKit becomes stable (at least 1.0.0 release is published).
SvelteKit reached version 1.0.0 today🚀 @pooledge I can dig into it if you could share a small repo with the issue?
Yay, I've heard! And thanks for coming back to me. Hopefully it's all here.
Whenever $app/stores
is a direct import and in use (tweak here: ./src/lib/unit.ts:4
) and I want to npm tun test
it, I need to find a way to mock it also. So I've tried to overrule the alias $app
using CT and its config — run npm run test:ct
— with the same result.
Oh, didn't you ask for a repo, did you? Minimum repro @ GH.
Thanks!
Oh, didn't you ask for a repo, did you?
Thanks!
Found out how to download it, thanks anyway!
I've also stumbled upon a problem while resolving a module containing purely .env
vars, e.g. $env/static/public
. After defining a proper alias, I cannot wind a way to re-use the existing .env
:
import dotenv from 'dotenv';
dotenv.config();
export const PUBLIC_APP_URL = process.env.PUBLIC_APP_URL;
and process
is undefined.
Is there a proper way to do it?
Hi, SvelteKit maintainer here. I think this should probably be implemented a bit differently in Playwright and can probably use Storybook as a guide. See my comment here: https://github.com/microsoft/playwright/issues/18825#issuecomment-1421523694
@benmccann could you explain this a bit in more depth as I have never worked with Storybook. Thank you 🙏
Did anyone manage to find a workaround?
I know this is a lot to task, but does someone from the Playwright team know if adding support for Sveltekit is something that would be implemented anytime soon?
I'm tasked with developing component tests, with either Playwright or Storybook. I think it would be awesome to do with Playwright component testing because the API is familiar to what developers already know from integration and e2e testing.
And thanks for the great testing tool Playwright is ✨
I wanted to add component testing to the svelte-headlessui library, and tried to do so using Playwright's component testing. I'm aware that playwright-ct (@playwright/experimental-ct-svelte
) was/is still experimental, but I was willing to spend time on making it work solely because my past experience with playwright e2e (@playwright/test
) had been positive. However, this was not the case with playwright-ct. There was no single blocking issue, but rather a mix of small ones (lack of sveltekit documentation and examples, recommended test structure).
I'm aware how this anecdote provides little in terms of concrete and actionable points, but I'm describing my experience in order to draw attention in hopes that playwright-ct would provide better sveltekit support as playwright-ct moves towards a stable release.
Playwright e2e testing, on the other hand, works great with sveltekit. So much so that when scaffolding a new app (by running npm create svelte@latest myproject
then selecting "app"), users are asked whether they want playwright set up for e2e testing. If so, sample config and test files are automatically added for users to quickly get up and running. It'd be great if playwright-ct support for sveltekit improves to the point where something similar can be done for users who are scaffolding a sveltekit component library (currently done by running npm create svelte@latest myproject
then selecting "library").
I'd like to use Svelte component testing feature in order to sort of unit test some ts libraries used across my SvelteKit application. This way I could use Playwright for everything.
The problem I currently stumbled upon is as follows: path import convention
$app/stores
doesn't seem to resolve correctly, despite overriding config as suggested here:and
./playwright/mocks/app
containingstores.ts
:What I'm getting is
Error: Cannot find package '$app'
, and, while$lib
and other aliases are resolving correctly, my guess is that$app
cannot not be overwritten.I've also tried to move mocks to other directory and resolving with a
__dirname
with no avail so far. Any ideas?