Yes 😅 and react + vitest

Just a regular ol' post, because there's still a _lot_ of projects using jsdom out there

web test runner, and vitest browser mode 🩵

WTR has been around so long, I wish people adopted that more at the time. But at least vitest has joined the game too now

Great work by @fuzzyma.bsky.social doing the talk! Wish I could have made it 🙏

it'll essentially turn an exported typescript function into an MCP tool and install the deps for you

so e.g. it can use tmcp by @paolo.ricciuti.me and scaffold the setup

very cool, i always forget chrome can collect css coverage

would be great to see more use of this and drop some bytes 👀

because, in this case of `listUsers`, im seeing it as "choose a caching strategy for this function". the fw/tools implement that in runtime code for you

if for w/e reason i wanted to cache that clientside unknown to the server, i'd write separate explicit client-only code (by choice)

if you'd like to chat about this a bit deeper some day i'd also love to FWIW. i feel like i must be missing something or it really does mean i'd just architect my userland code in a way that this isn't useful to me personally

given we could build that with either approach (mixing server/client, or having explicit files), it suggests to me we're just left with personal preference. someone somewhere prefers mixing client/server code and someone else doesn't?

if i want to cache that, i'd annotate the listUsers function somehow. decorators, jsdoc, imaginary funcs, whatever you prefer that the build process can pick out and understand. the runtime RPC logic would be setup with the right cache impl on whatever end (cli/serv) you configured

e.g. `listUsers()` is a func defined entirely in `users.server.ts`. when i author my client code, i import from that file and call `await listUsers()`. under the hood, RPC or whatever preferred form of comms to call the real thing at runtime

i probably need a more concrete example that isn't "query/action"

since this still sounds to me like plumbing to around the function rather than the impl itself. as in you'd just author it as a server.ts file and the fw does the rest

yeah query runs server only in my head too, this is where i was getting confused

i can't actually think of a use case where i'd want a mixture of client/server in one file since i just wouldn't structure it that way. so this probably all drills down to preference of architecture