Closed AdrianGonz97 closed 1 week ago
Latest commit: b6d91be066bdca2244b2fe4b0de265e441420a8b
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
pnpm add https://pkg.pr.new/sveltejs/cli/sv@275
pnpm add https://pkg.pr.new/sveltejs/cli/svelte-migrate@275
commit: b6d91be
Ohhh and there is another thing I just noticed: How are the directory names inside .test-output/_tests
generated? Here are my directories inside drizzle
-1930824653_0
-1930824653_1
-1930824653_2
-1930824653_3
-1930824653_4
-1930824653_5
-1930824653_6
-1930824653_7
They are semi-useful at least. In #32 I generated them based on the options passed for each test, so that if a test failed you could identify it by directory name and run it by hand.
How are the directory names inside
.test-output/_tests
generated? Here are my directories insidedrizzle
they're based on the task id provided by vitest. Each test gets their own meta.json
(similar to how we had it in svelte-add
) that documents the options that were passed in.
They are semi-useful at least. In #32 I generated them based on the options passed for each test, so that if a test failed you could identify it by directory name and run it by hand.
not sure if that's a scalable solution. imagine having multiple test cases that share the same addon options but they evaluate different things
they're based on the task id provided by vitest. Each test gets their own
meta.json
(similar to how we had it insvelte-add
) that documents the options that were passed in.not sure if that's a scalable solution. imagine having multiple test cases that share the same addon options but they evaluate different things
Ohhh, i saw that file, but didn't look into it. Was confusing it with this: https://github.com/sveltejs/cli/blob/main/packages/create/templates/demo/.meta.json. Then im totally fine.
Alternative to #32
This takes more of a lightweight approach where we provide a bare minimum api for testing rather than controlling the whole testing pipeline. This should allow for better flexibility as we're no longer tied to any particular testing framework.
Notes:
v8.3.x
asv8.4.x
flat out doesn't work. I haven't had a moment to fully investigate the issue yet.TODO:
degit
to clone the vite templates? If so, should we pin it to a specific commit hash (see here)? Or should this be something we manage fully (perhaps as part ofcreate
)?