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.

Related:

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.

There are a lot of little things that are vaguely irritating, but not so entirely off-putting that the internet wouldn’t use it. After all the world runs on JavaScript.

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 with 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 used lightly.

Packages

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 https://wa9ace.net/deno/pkg/daro/v0.0.1/mod.ts.

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

Answer: deps.ts 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.