Good. just one more thing to ask. Does the project's setup or toolchain matter? Or Are there any conventions I have to follow?

Thanks,@eps1lon for that reply. Indeed, that's a very good approach.

Does the project's setup or toolchain matter? Or Are there any conventions I have to follow?

It'd be good if you base your initial repo structure off of copying the way jest-dom is set up. In particular, the way the package json scripts section works, which is mostly based on kcd-scripts, and how it does versioning. This will allow the automated semantic versioning to work, and make it easier to automate releases on PR merges.

Okay, I'll try to set up the structure and the scripts as is injest-dom, but do you mind if I usetypescript,vitest, and probablypnpm (for better developer experience)?

About TypeScript, definitely.

About vitest and pnpm, I have never used them, so I may be negatively biased here, but I would not want this package to divert too much from the developer experience in all the other packages in testing-library. It is my understanding that we mostly use jest and npm. But feel free to make your case here if you feel strongly about it. Or let's see what others think.

@gnapse@eps1lon@kentcdodds

Hey again, It's been quite a while 😁, and eventually, I got some time and wrote a couple of assertions. Here's therepo. There ain't much but I think it's enough for an alpha release to test if the API integrates properly withjest-dom. At the same time, I can continue adding more assertions and startcypress-dom as well.