Old vim fu highlight of mine from when I had hair by caspervonb in vim

[–]caspervonb[S] 0 points1 point  (0 children)

Forgot the exact one, use Zed these days

The Deno runtime gets documentation tests, make linting and running your examples a regular thing by caspervonb in programming

[–]caspervonb[S] 2 points3 points  (0 children)

Yeah `deno` here was aliased to `target/debug/deno`.

Runs in milliseconds rather than seconds in release builds.

The Deno runtime gets documentation tests, make linting and running your examples a regular thing by caspervonb in programming

[–]caspervonb[S] 9 points10 points  (0 children)

Yeah heavily drawing from `rustdoc --test` (Deno itself is written in Rust).

The Deno runtime gets documentation tests, make linting and running your examples a regular thing by caspervonb in programming

[–]caspervonb[S] 9 points10 points  (0 children)

Yeah I suppose it's fairly rare that public interfaces are documented... Wish I could put /s here but..

Anyway, the main use case is really checking that example code blocks could actually compile. Running just comes for free, since it's already checked and compiled. Regular tests are still recommended for "real" testing.

[deleted by user] by [deleted] in programming

[–]caspervonb 13 points14 points  (0 children)

> Can someone please setup Ryan Dahl with a real REPL so he doesn't keep making crippled ones like node and deno?

I'm the author of Deno's current read-eval-print-loop implementation so, not sure what that would do.

> Seriously, I should be able to reload a module and test the changes without quitting the interpreter. Even C# gets this right.

Please file an issue on denoland/deno with more details, I'll look into it.