Trying Deno

3 min readJan 30, 2022

Deno is a Typescript/JavaScript runtime from the creators of Node. Scripts are run with the command deno run

deno run script.ts

This article is written based on the 1.17.1 version. It aims to summarise the learnings gained while creating a very simple prototype.

No build

Deno executes Typescript natively; no need to transpile to JavaScript.

No install

Deno consumes modules with a bare import, e.g.

import { serve } from "https://deno.land/x/sift@0.4.2/mod.ts";

No install step and no node_modules folder!

Declare module versions with @x.x.x

More subcommands

Lots of subcommands! e.g.

deno fmt
deno lint
deno doc
deno eval

Built-in test runner

Use deno test to run test cases.
https://deno.land/manual@v1.18.1/testing

Example test file:

import { assertEquals } from "https://deno.land/std@0.119.0/testing/asserts.ts";Deno.test("should return false for invalid payload", () => {
  const response = validatePayload([]);
  assertEquals(response, false);
});

Secure defaults

Unless allowed, Deno scripts can’t access files, the environment, or the network. To specify permissions, set arguments on the subcommand, e.g.

deno run -allow-net script.ts

Web Platform APIs

In an attempt to harmonise the front and back end JavaScript environments and the promise of isomorphic code, Deno aims to use web platform APIs wherever possible.

Standard library

Created by the Deno team, a standard library covers many core needs.

e.g.

import {
	getCookies,
	setCookie,
} from "https://deno.land/std@0.120.0/http/mod.ts";

deno.land/x

This is a hosted service maintained by the Deno team. It hosts cached and versioned open source modules from GitHub.

ES Modules

Deno can only import JavaScript written as ES modules, the current browser module standard.

To make use of libraries in the JavaScript eco-system that use other formats like CommonJS, services like Skypack and ESM have been created. They proxy popular registries like npm and convert the libraries into ES modules.

Both Skypack and ESM will also serve type definitions for the module using the X-TypeScript-Types header. Skypack requires ?dts added to the end of the module URL.

Manage module versions

Because there is no package.json, a useful pattern to see module versions in one place is to re-export dependencies from a file called something like deps.ts.

export { S3Bucket } from "https://deno.land/x/s3@0.4.1/mod.ts";

Then import the package from deps.ts

import { S3Bucket } from “./deps.ts”

This ensures that you are using the same version everywhere.

It is also useful to separate development dependencies with the same technique, e.g. dev-deps.ts

export { stub } from "https://cdn.skypack.dev/sinon@12.0.1?dts";

Stubs

Using the re-export technique above it is straight-forward to stub modules because the code is already using an abstraction. In the test code we can replace the implementation of the abstracted module.

A library like sinon can make this easy e.g.

const signInStub = stub(firebase, "signInWithEmailAndPassword");
signInStub.resolves({ user: { uid: "uid" } } as any);

Routing

A lightweight routing option is sift.

import { serve } from "https://deno.land/x/sift@0.4.3/mod.ts";serve({
  "/": () => new Response("hello world"),
  "/blog/:slug": (request, params) => {
    const post = `Hello, you visited ${params.slug}!`;
    return new Response(post);
  },
  // The route handler of 404 will be invoked when a route handler
  // for the requested path is not found.
  404: () => new Response("not found"),
});

Very simple to define routes, although there is no syntax sugar for handling http methods.

dotenv

For local testing this was a very useful module; it loads environment variables from a file called .env

Remember to .gitignore this file if you have credentials in there!