scarf

> I've always thought that runtime checking if desired could be something that can be optionally generated from the static types, ie function wrapper that check, but I'm not aware...

https://github.com/denoland/deno-docs/blob/2c90cc2eca70c484e5fbfc61d256bf7342a2e95e/runtime/manual/references/contributing/style_guide.md?plain=1#L310-L327 maybe the test name rules could be documented in deno manual. should I open PR/issue?

yes. type definitions needs more polishing, however. for example, putting non-readonly array will result in `[]` for return type when it should be `T[]`

that's good to know. would i make a PR for case 1?

it's 2022.03

I'm for not type-checking all modules. unless it's REPL, it's highly unlikely modules are used without type checking. even in JS it can be easily enabled via `// @ts-check`.

sorry for the necropost, but this also causes infinite hanging. ```ts import { init } from "npm:z3-solver" const { Context } = await init() const { Int, And, solve }...

Hi, i'm interested in opening a PR [(~~totally not because my workflow failed~~)](https://github.com/scarf005/scarf005/actions/runs/7418372124/job/20186206007#step:2:993). May I get a pointer on where to look at, and preferred solution? also, should i open...

strange, for me the whole discord crashes as well when user types

I see. Also, would it be possible for denoify to transform files concurrently? Using asynchronous fs functions with `Promise.all` could improve performance if IO also bottlenecks. https://github.com/garronej/denoify/blob/5ad3bb2e08d59317f1132e9aeb9d469e60fd72ef/src/lib/denoify.ts#L150-L158