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
deno compilecan 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:
# Using Shell (macOS and Linux): curl -fsSL https://deno.land/x/install/install.sh | sh # Using PowerShell (Windows): iwr https://deno.land/x/install/install.ps1 -useb | iex # Using homebrew (MacOS): brew install deno # Using Scoop (Windows): scoop install deno # Using Chocolatey (Windows): choco install deno # Build from source using cargo 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
deno fmt, and
deno lint. Today we are pleased to add another
developer tool to the Deno toolchain:
deno compile does for Deno what
pkg do for Node: create a
code. This has been the single most upvoted issue on the Deno issue tracker.
It works like this:
$ deno compile --unstable https://deno.land/[email protected]/http/file_server.ts Check https://deno.land/[email protected]/http/file_server.ts Bundle https://deno.land/[email protected]/http/file_server.ts Compile https://deno.land/[email protected]/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
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.
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.
You might have noticed that unlike other tools that create standalone,
self-contained binaries for JS (like
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.
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
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.
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 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
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
For more details on this, see the Deno 1.5 blog post.
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
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
channel. Canary releases are made multiple times a day, once per commit on the
master branch of the Deno
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
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.
rusty_v8 v0.14.0 targeting M1 are also
provided with the
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
The full release notes, including bug fixes, can be found at https://github.com/denoland/deno/releases/tag/v1.6.0.