WWRS

Better way of figuring that one out: ``` if (position.y > 0.0) { // Top } else if (position.x > 0.0) { // Right } else { // Left }...

Deno's `it` tests use `Deno.test` internally, so matching Jest's behavior here might require changing `Deno.test`. Considering https://github.com/denoland/deno/pull/29222 just merged, I would say it's worth opening an issue in that repo.

`exists` has an option `isReadable`, does that cover your use case? ```ts import { exists } from "jsr:@std/fs@^1.0.15"; console.log(await exists("/root/foo", { isReadable: true })); ```

Changing a certain regex in `deno_doc` from ...`\{([^}]+)\}`... to ...`\{(.+)\}`... (allowing `}` between the braces) does fix this. https://github.com/denoland/deno_doc/blob/aef1632661cd6681f471e615e8c415c3b987b4b3/src/js_doc.rs#L27 Unfortunately, that's not a permanent solution, since the performance of `.+`...

Thoughts on an option like `checkPadding` or `ignorePadding`? What should the default be?

Thoughts on doing this for other types as well? I get similar 10000-line diffs from ```ts const aobj = Object.fromEntries(a.map(n => [n, n])) const bobj = Object.fromEntries(a.map(n => [n, b[n]]))...

Of the options, I like 3 the best. It seems least intrusive. I can implement this if approved.

Currently `expect.hasAssertion` is not supported in `Deno.test` but there's no indication of this (#6518). The specification of that function requires it be checked at the end of the test, and...

Changed to draft because I realized this makes behavior different when objects have properties: https://github.com/denoland/std/issues/6334#issuecomment-2730103563

We would need to disambiguate the behavior mentioned in #6334. Determining this behavior doesn't seem like a priority, so if this PR is not moving toward either being outright accepted...