I’ve very much enjoyed all of my experiences with Deno and I’ve wanted to share that experience along with frequent questions I’ve been asked.
- Watch me live code a new high performance Deno webserver
- How to Debug Deno in VSCode
- Deno Command Cheatsheet
How things are (were?)
Imagine if you will a TypeScript node project similar to this project skeleton I took a few hours to whip together.
This skeleton has:
- TypeScript Express
- TypeScript aware tests with Jest
- TypeScript aware linter with ESLint
To produce that you need upwards of 2k+ packages, and 3 different config files with vaguely similar rules to have them all behave cohesively. This is all not to mention how difficult it is to get debugging in VSCode going with properly mapped files, testing, and breakpoints. Imagine you’re a newer developer. You don’t have a mentor able to walk you through setting up a new project with a TypeScript stack so you can start writing something, anything, useful. How about from another perspective. Do you trust that your linter isn’t silently shipping data off of your machine across the network? If you aren’t vetting your dependencies you should be.
This death by a thousand cuts can be a slog and irritating to keep updated, with packages required just to keep your project’s source code compiling, tests passing, and linter fixing, a cluster of issues.
What Deno Provides
Deno seeks alleviate many of these issues. Deno has a built-in functionality for
almost everything we’ve discussed above. First of all Deno has a TypeScript
compiler built in, with plans to
port all of TSC to Rust! It has
testing built in out of the box with
deno test along with a built in formatter
deno fmt. What’s even better is that this requires no extra dependencies,
and no configuration to support TypeScript. It Just Works™. Another piece of
functionality Deno ships with is the ability to restrict application’s abilities
with a whitelist permission system. If you’re program doesn’t need any network
access or filesystem access then you can simply run your deno program with
deno run. If you need network access to specific domains, and filesystem
access to specific folders you will need to declare that when invoking the
program. Something similar to
deno run --allow-read=/etc --allow-net=github.com,deno.land your_program.ts.
-A will blanket allow all permissions, but that’s not something that should be
Deno imports packages via URL and takes a completely different approach from Node’s NPM ecosystem. There is no centralized package management system. There is deno.land/x however there is discussion regarding whether or not it remains to be a good idea to provide a centralized mirror for simple files hosted on GitHub.
I plan to release modules under my own namespace using this sort of structure
Deno allows you to produce a lockfile so that if a dependency’s hash changes between first use and the next reload you can inspect to see why, as well as providing a way to vendor dependencies so that you don’t have to rely on anyone’s, including my own, dependencies being available on any given server.
But I don’t want super long imports all over my codebase
as recommended in the deno.land/manual
What’s the convention for publishing packages if there’s no NPM?
Essentially projects have a
mod.ts file that rexports the public parts of the
library you’re using. This makes the steps for publishing a package quite easy
as all you really need is your TypeScript code, a place to put it online, and a
mod.ts file that exports the part of your code that you want published.