chore: add initial tests to repo

[brettkolodny]

Closes #45

The initials tests in this PR cover basic UX and form rendering. There are some questions around how much really needs to be tested within this repo as testing everything would lead to a lot of duplicate with the tests that already exist within coder/coder.

Going forward I think the best ways to increase test coverage for this repo are:

• Figure out how to actually run the wasm code within tests
  • Currently all of the wasm code is mocked and the preview is being tested on static outputs. This limits our ability to test the dynamic part of dynamic parameters. Vite has some wasm plugins but the way Go operates seems to complicate this slightly.
• Work on a more graceful way to share coder between coder/coder and other repos
  • The actual components for dynamic parameters are being vendored from coder/coder with minimal change. It'd be nice if instead of this code being copy-pasted and then modified we had a better system for keeping the two code bases in sync. This would help with confidence in terms of tests in coder/coder applying to this repo.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 4, 2025 4:03pm

[Kira-Pilot]

@brettkolodny, can you please chunk this up so we can review? 2k+ LOC is a lot to look at in one shot and you'll get a more meaningful review if your diffs are smaller, e.g. ~500 LOC.

[brettkolodny]

It looks scarier than it is but the majority of those line changes are in the pnpm lock file which can essentially be ignored as it should mostly be from the new packages added in the package.json.

I was having some pnpm issues after after a workspace update which could lead to big lockfile changes if I accidentally changed the pnpm version but I'm not seeing a change in the lockfile version so I think it's correct?

[Kira-Pilot]

It looks scarier than it is but the majority of those line changes are in the pnpm lock file which can essentially be ignored as it should mostly be from the new packages added in the package.json.

That makes sense! Seems like a 1k+ line diff even discounting the lockfile so I would still recommend chunking it.

I was having some pnpm issues after after a workspace update which could lead to big lockfile changes if I accidentally changed the pnpm version but I'm not seeing a change in the lockfile version so I think it's correct?

Looks like we're not pinning a pnpm version so maybe we could try that (in a separate PR) to avoid drift in the future.

[brettkolodny]

Will do! Going to move this PR to draft now and separate it out into two different PRs

[brettkolodny]

First PR, I don't love having branches/PRs off of other branches that aren't main so I'll open up the next one after this one is submitted