Where does Deno Code Come From

Whenever I sit down with a new (either to me, or to the world) programming language, the first thing I end up doing is trying to understand where all the code I’ll use comes from. What’s available by default, what can I import/include, how does importing code work, how is third party code distributed.

Here’s what I found when I looked at Deno, the new Javascript runtime from (in part) one of the original NodeJS engineers.

This article assumes you’ve got a version of Deno up and running on your server.

Deno’s Built In Functions and Methods

At 1.0, the Deno runtime gives you around 160 functions, methods, and variables to play with. Some are global, some are on the global Deno object. They will always be there for you.

Your Other Code

Deno’s import statement can load ES Modules using the import statement and a relative path.

For example, create two files that look like this

// File: main.js
import {Messages} from "./messages.js"
const messages = new Messages;
console.log(messages.hello)

// File: messages.js
export class Messages {
  hello = "hello world"
}

and then run the program in main.js

$ deno run main.js
hello world

Here our program in main.js imported the Messages class from the ES modules defined in messages.js

By supporting ES modules, Deno will let you organize your program however you like.

Other People’s Code

Deno, somewhat (in?)famously, has no built-in or ships-by-default package/dependency manager.

Instead, Deno allows you to import files from any url. This means someone can upload an ES module to a URL, and you can import that module into your program

import {Messages} from "http://example.com/path/to/messages.js"
const messages = new Messages;
console.log(messages.hello)

In the above program Deno will, behind the scenes, download the path/to/messages.js file to your local computer once, and then run the file from your computer in the future. Deno will download these imported files to whatever path is configured in your DENO_DIR shell enviornment variable.

$ export DENO_DIR=/foo/baz/bar

These downloaded dependencies may not be stored in a format you recognize, and Deno doesn’t appear to publish/promise anything about how they’re stored.

If you don’t have a DENO_DIR configured, Deno will use a cache directory on your computer, which will vary depending on your operating system.

• *nixes: $XDG_CACHE_HOME/deno or $HOME/.cache/deno
• Windows: %LOCALAPPDATA%/deno (%LOCALAPPDATA% = FOLDERID_LocalAppData)
• macOS: $HOME/Library/Caches/deno

The manual also includes this cryptic warning

If something fails, it falls back to $HOME/.deno

All this means if someone wants to share some javascript code, all they need to do it upload it to a web server.

This also means you, as the program writer, are responsible for managing your own dependencies. Deno’s manual suggests putting all your HTTP based imports in a deps.ts file, but there’s nothing (at this time) in Deno enforcing this.

Deno’s Other Code

When it comes to Deno, the runtime, the built-in functions and the ability to import other people’s code via http(s) is all you get.

However Deno, the project, has more to offer you. The Deno Standard Library is a website that contains a bunch of different ES modules (implemented in typescript) offering you functionality beyond the 160 or so default functions, methods, and variables built into the Deno runtime. The Deno Standard Library website also offers an opinionated way to organize a website of ES modules.

For example, lets consider the logger from the standard library

import * as log from "https://deno.land/std/log/mod.ts";
log.debug("Hello world");

The above program will always download the latest version of the standard library’s logger module. You can (and probably should) grab a specific version by using a different URL

import * as log from "https://deno.land/std@0.51.0/log/mod.ts";
log.debug("Hello world");

The second program above will always download version 0.51.0 of the logger module. This is not because of anything special in the Deno runtime, it’s just because the folks who run the Deno Standard Library website have decided that version 0.51.0 will live at the URL https://deno.land/std@0.51.0/log/mod.ts. This is a convention. It’s a convention that carries extra weight because this website is run by the same people who control the open source code that implements Deno, but it’s still just a convention.

Also – if you’re wondering why visiting a URL like https://deno.land/std@0.51.0/log/mod.ts in a browser gives you a nice HTML page instead of just the code — the Deno Standard Library website is smart enough to serve browsers one sort of content, but serve Deno the actual code. Fans of the HTTP protocol might find these curl commands enlightening.

$ curl -H "Accept: text/plain" https://deno.land/std@0.51.0/log/mod.ts

$ curl -H "Accept: text/html" https://deno.land/std@0.51.0/log/mod.ts

Deno’s OTHER Other Code

In addition to the Deno’s Standard Library, the Deno website also hosts third party code under the /x URI. Here’s an example of importing the third party ask module into your system.

import Ask from 'https://deno.land/x/ask@1.0.0/mod.ts';

const ask = new Ask();
ask.prompt([{
  name: 'conan',
  type: 'input',
  message:'What is best in life?'
}])

Again — there’s nothing magic here. The Deno runtime is downloading this module from the Deno website. The versioning of this this code follows the same conventions as the versioning of the standard library. Conventions within a particular third party module may vary from the conventions inside Deno’s standard library, as this code comes from people out in the world.

If you want to distribute code via the Deno website (i.e. you wish to be a third party), it looks like you need to convince a maintainer of the denoland/deno_website2 repository to let you edit their databases.json. The https://deno.land website uses this file to turn a GitHub repository into a set of downloadable typescript files hosted on http://deno.land/x.

Wrap Up

So in summation —

1. The Deno runtime has a small number of built in functions and methods
2. Deno’s built-in import statement will let you download additional code from anywhere on the internet.
3. The https://deno.land website hosts a “standard library” of code for Deno, as well as a collection of third party modules

It’s a simple, if primitive, setup for managing dependencies and distributing code. I imagine Deno’s first few years post-1.0 will have equal parts folks building package managers on top of this system, and individual projects spending way more time on managing their dependencies.