dsherret

One shotting slop is very different from iterating back and forth with an AI. Also, most of the AI work that's being done has been getting node compatibility tests passing with the help of comparing that to the Node.js code, which is something an LLM is very good at.

The benefit is you can easily scale the complexity of the file. An .sh file is great for simple commands, but with a .ts file with Deno you can pull in a complex dependency with one line and write logic more succinctly.

To be clear for people reading wondering what this is about, this is only a hard recommendation for the public API types. The reason for it, is by adding explicit types to the boundary of your package, the package becomes way faster for users to type check because every user's machine doesn't need to do all the inference work and type check internal types or packages not related to the types. Additionally, it makes the published code more resilient to changes to TypeScript's inference in the future because it's not doing inference. It also becomes way easier to generate documentation for the package (also, the ability to generate .d.ts or bundled .d.ts files without a type checker becomes easier).

Right now, the publish command errors and asks you to fix the issues or bypass it entirely via `--allow-slow-types`. In the future there will be a `--fix` flag to write the explicit types for you.

It's being renamed to a no-slow-types lint rule that occurs on publish and in deno lint. Essentially it enforces that the types of the public API can be determined without inference. This enables a few things:

1. Type checking ts sources is really fast when Deno determines a package does not use slow types. It may entirely drop packages and modules that aren't relevant for type checking. It also skips parsing and building symbols for the internals of a package (ex. function bodies).

2. Documentation is really fast to generate (doesn't need a type checker).

3. A corresponding .d.ts file for relevant typescript code is automatically created for Node.

In Deno with JSR, only the public API gets used for type checking because publishing enforces that the public API can be determined without type inference. So it's similar to declaration files (d.ts files) and you wouldn't see errors that occur at the non-declaration level unless someone explicitly opted out of those publishing checks (which is heavily discouraged).

For Deno there is https://github.com/dsherret/dax which is also zx inspired and has a cross platform shell built-in.

You can already mostly do this with dprint's TypeScript plugin if you tweak the config (and I'm open to adding more config to support this scenario in case something is missing). For example, the TypeScript team uses a line limit of 1000: https://github.com/microsoft/TypeScript/blob/1797837351782e7...

> Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking.

This is not the case. The Deno runtime itself is not tied to the Deno Deploy hosting service. The KV feature in the Deno runtime can be used without the hosting service.

You can read the details about how Deno KV works in the Deno runtime here: https://til.simonwillison.net/deno/deno-kv (as has been posted in other comments)

Seems like there's one here: https://github.com/benfoxall/lastfm-to-csv

The `deno cache` command (ex. `deno cache main.ts` or `deno cache --node-modules-dir main.ts` if you want a node_modules folder) will ensure all npm packages used in the provided module are cached ahead of time. It acts similarly to a `npm install` if you need it.

Also, at the moment, npm specifiers aren't supported with `deno compile` (https://deno.land/manual@v1.28.0/tools/compiler), but in the future that will be one way to have a self contained executable with everything ready to go.

No, the --node-modules-dir flag doesn't create a symlink to the home directory cache. It creates a copy in the node_modules folder (in the future it will use hardlinks to reduce space, there is an open issue). It's stored at node_modules/.deno/<package-name>@<version>/node_modules/<package-name> (that flag is heavily influenced by pnpm)

You can do a patch package by doing something like the following (and then you can move this into a `deno task` https://deno.land/manual@v1.28.0/tools/task_runner when launching your app to ensure it happens):

    deno cache --node-modules-dir main.ts
    deno run --allow-read=. --allow-write=. scripts/your_patch_script.ts
    deno run --node-modules-dir main.ts

Node API will be supported sometime soon https://github.com/denoland/deno/pull/13633

We'll have custom registry support. For local npm packages, that would be nice to have, but probably something that will be implemented later. It could actually be done in a hacky way with the existing implementation of this we have, but it would be better to have something specifically designed for this.

Deno already analyzes the entire module graph before the application starts up, so we extract out the npm specifiers ahead of time, do the npm dependency analysis, cache any packages as needed, then start execution.

Fresh has had a lot of development since then. See the "Production Ready" section in blog post for the latest thoughts:

> Fresh 1.0 is a stable release and can be relied upon for production use. Much of Deno's public web services use Fresh (for example the site you are reading this blog post on now!). This does not mean we are done with Fresh. We have many more ideas to improve user and developer experience.

Type checking still occurs for `deno test`, which is what's mostly used for development. `deno run` won't have it by default because usually you run programs that are already type checked, but if you want it you will be able to add the `--check` flag (ex. `deno run --check main.ts`).

There's a huge performance overhead to run type checking, so the changes are for it to only be run for development/bundling workflows and be opt-in otherwise.

There is one here: https://github.com/dprint/dprint-vscode

It's definitely something I would like to implement. I haven't found a parser that would be good for formatting yet so maybe I will have to write my own :/

I know. I've been wondering if there's a way this complexity could be buried in the GitHub action for dprint (https://github.com/dprint/check) so people would only have to specify that and everything would just happen, but I'm not sure it's possible at the moment. Caching seems to be limited to needing to use actions/cache (https://github.com/actions/cache)

The title of the article was and is "Speeding up Prettier locally and on your CI with dprint". If you use the Rust-based plugins instead of Prettier it will be much faster as noted at the end of the article.

To add another advantage of using dprint not mentioned, is that since it's pluggable you can use Prettier and other formatters all from the same formatting CLI. The main dprint repo does this in its dprint.json (https://github.com/dprint/dprint/blob/3d822a48133358ec4e2d5b...)

Yes, the 40x faster is only for the runs after the first in this scenario. That said, if I disable the incremental cache locally (dprint check --incremental=false) and run this on the example code linked to in the article, on my machine the first run is 8.0s. If I run prettier's CLI it's 24.8s. dprint is faster because it formats files in parallel with Prettier and has Prettier snapshotted in a Deno runtime. There's some thread contention that's making it a little slower than it could be with v8 and I've been lazy to investigate it.

Also, dprint uses very fast globbing with two threads working together in order to collect files. I would guess Prettier would still be slower if it did this because it's programmed in JS (though not by much), but it doesn't do it.

To be clear, I created this site quickly on Deno Deploy this weekend (I'm the author) and didn't bother getting a proper domain yet. Hacker news is cutting off the subdomain of david.deno.dev and this is just a personal post about the dprint CLI and dprint-plugin-prettier, which aren't available in Deno's CLI.

Deno does use some other Rust-based dprint plugins for deno fmt though and dprint-plugin-prettier uses an embedded Deno runtime with Prettier snapshotted in it. Also, Deno now has a similar built-in incremental formatting and linting as of 1.21 last week, so those subcommands finish almost immediately after the first run... though they were already very fast https://deno.com/blog/v1.21#incremental-formatting-and-linti...

The equivalent in Deno is:

  $ deno eval -p "1 + 1"
  2

Just to be clear, `deno eval "console.log(5)"` has existed for some time which is similar to `node -e "console.log(5)"`. In this case, the deno repl subcommand's --eval flag provides a cross-platform way to evaluate some setup code before launching into the REPL. This is useful if you alias the command in your shell's initialization file allowing you to easily launch a REPL with everything already setup to your liking.

For example:

  $ alias add_repl='deno repl --eval "const add = (a, b) => a + b"'
  ...
  $ add_repl
  Deno 1.13
  exit using ctrl+d or close()
  > add(1, 2)
  3