Today we are releasing Deno 1.6.0. This release contains some major features, and many bug fixes. Here are some highlights:

• Build self contained, standalone binaries: deno compile can build your Deno projects into completely standalone executables
• Built-in Deno Language Server: fully integrated LSP for code editors
• Experimental support for Mac Arm64: release binaries that run natively on Apple’s new M1 chip.

If you already have Deno installed you can upgrade to 1.6 by running deno upgrade. If you are installing Deno for the first time, you can use one of the methods listed below:

curl -fsSL https://deno.land/x/install/install.sh | sh


iwr https://deno.land/x/install/install.ps1 -useb | iex


brew install deno


scoop install deno


choco install deno


cargo install deno

New features and changes

deno compile: self-contained, standalone binaries

We aim to provide a useful toolchain of utilities in the Deno CLI. Examples of this are deno fmt, and deno lint. Today we are pleased to add another developer tool to the Deno toolchain: deno compile.

deno compile does for Deno what nexe or pkg do for Node: create a standalone, self-contained binary from your JavaScript or TypeScript source code. This has been the single most upvoted issue on the Deno issue tracker.

It works like this:

$ deno compile --unstable https://deno.land/std@0.79.0/http/file_server.ts
Check https://deno.land/std@0.79.0/http/file_server.ts
Bundle https://deno.land/std@0.79.0/http/file_server.ts
Compile https://deno.land/std@0.79.0/http/file_server.ts
Emit file_server

$ ./file_server
HTTP server listening on http://0.0.0.0:4507/

As with all new features in Deno, deno compile requires the --unstable flag to communicate that there may be breaking changes to the interface in the short term. If you have feedback, please comment in the Deno discord, or create an issue with feature requests on the Deno issue tracker.

For implementation details, see #8539.

Current limitations

For now there are several limitations you may encounter when using deno compile. If you have a use case for one of these, please respond in the corresponding tracking issues.

• Web Workers are not currently supported. The tracking issue for this feature is #8654.
• You can not dynamically include code with dynamic import. The tracking issue for this feature is #8655.
• Customizing V8 flags, and sandbox permissions is not currently possible. The tracking issue for this feature is #8656.

Future plans

You might have noticed that unlike other tools that create standalone, self-contained binaries for JS (like pkg), deno compile does not have a virtual file system that can be used to bundle assets. We are hoping that with future TC39 proposals like import assertions, and asset references, the need for a virtual file system will disappear, because assets can then be expressed right in the JS module graph.

Currently the deno compile subcommand does not support cross platform compilation. Compilation for a specific platform has to happen on that platform. If there is demand, we would like to add the ability to cross compile for a different architecture using a --target flag when compiling. The tracking issue for this is #8567.

Due to how the packaging of the binary works currently, a lot of unnecessary code is included the binary. From preliminary tests we have determined that we could reduce the final binary size by around 60% (to around 20MB) when stripping out this unnecessary code. Work on this front is happening at the moment (e.g. in #8640).

Built-in Deno Language Server

Deno 1.6 ships with a new deno lsp subcommand that provides a language server implementing Language Server Protocol. LSP allows editors to communicate with Deno to provide all sorts of advanced features like code completion, linting, and on-hover documentation.

The new deno lsp subcommand is not yet feature-complete, but it implements many of the main LSP functionalities:

• Code completions
• Hints on hover
• Go to definition
• Go to references
• deno fmt integration
• deno lint integration

The Deno VSCode extension does not yet support deno lsp. It is still more feature rich than the nascent deno lsp can provide. However, we expect this to change in the coming weeks as the LSP becomes more mature. For now, if you want to try deno lsp with VSCode, you must install VSCode Deno Canary. Make sure that you have installed Deno 1.6 before trying this new extension. And make sure to disable the old version of the extension, otherwise diagnostics might be duplicated.

To track the progress of the development follow issue #8643. We will release a new version of vscode-deno that uses deno lsp when #8643 is complete.

Migration to stricter type checks complete

In Deno 1.4 we introduced some stricter TypeScript type checks in --unstable that enabled us to move a bunch of code from JS into Rust (enabling huge performance increases in TypeScript transpilation, and bundling). In Deno 1.5 these stricter type checks were enabled for everyone by default, with a opt-out in the form of the "isolatedModules": false TypeScript compiler option.

In this release this override has been removed. All TypeScript code is now run with "isolatedModules": true.

For more details on this, see the Deno 1.5 blog post.

TypeScript 4.1

Deno 1.6 ships with the latest stable version of TypeScript.

For more information on new features in Typescript 4.1 see Announcing TypeScript 4.1

Canary channel

For advanced users that would like to test out bug fixes and features before they land in the next stable Deno release, we now provide a canary update channel. Canary releases are made multiple times a day, once per commit on the master branch of the Deno repository.

You can identify these releases by the 7 character commit hash at the end of the version, and the canary string in the deno --version output.

Starting with Deno 1.6, you can switch to the canary channel, and download the latest canary by running deno upgrade --canary. You can jump to a specific commit hash using deno upgrade --canary --version 5eedcb6b8d471e487179ac66d7da9038279884df.

Warning: jumping between canary versions, or downgrading to stable, may corrupt your DENO_DIR.

The zip files of the canary releases can be downloaded from https://dl.deno.land.

aarch64-apple-darwin builds are not supported in canary yet.

Experimental support for Mac Arm64

Users of the new Apple computers with M1 processors will be able to run Deno natively. We refer to this target by the LLVM target triple aarch64-apple-darwin in our release zip files.

This target is still considered experimental because it has been built using Rust nightly (we normally use Rust stable), and because we do not yet have automated CI processes to build and test this target. That said, Deno on M1 fully passes the test suite, so we’re relatively confident it will be a smooth experience.

Binaries of rusty_v8 v0.14.0 targeting M1 are also provided with the same caveats.

Changes to std/bytes

As a part of the efforts of the Standard Library Working Group; std/bytes module has seen major overhaul. This is a first step towards stabilizing the Deno standard library.

Most of the APIs were renamed to better align with the APIs available on Array:

• copyBytes -> copy
• equal -> equals
• findIndex -> indexOf
• findLastIndex -> lastIndexOf
• hasPrefix -> startsWith
• hasSuffix -> endsWith

The full release notes, including bug fixes, can be found at https://github.com/denoland/deno/releases/tag/v1.6.0.