← Back to context

Comment by WorldMaker

3 hours ago

- I replaced a mess of prettier config files, eslint config files, tsconfig files, npm install scripts for all the above plus the typescript eslint config plugin for deno fmt, deno lint, deno check. It's nice to have that all in one place.

- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.

- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.

- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.