dsherret
Joined 5 years ago
Karma
91
Submissions
27
Member since
Jun 18
Recent submissions
Comment · 5 months ago
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.
Comment · 9 months ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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).
Comment · 2 years ago
For Deno there is https://github.com/dsherret/dax which is also zx inspired and has a cross platform shell built-in.
Comment · 2 years ago
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...
Comment · 3 years ago
> 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)
Comment · 3 years ago
Seems like there's one here: https://github.com/benfoxall/lastfm-to-csv
Comment · 4 years ago
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/[email protected]/tools/compiler), but in the future that will be one way to have a self contained executable with everything ready to go.
Comment · 4 years ago
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/[email protected]/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.tsComment · 4 years ago
Node API will be supported sometime soon https://github.com/denoland/deno/pull/13633