December 8, 2020
Bartek Iwańczuk, Luca Casonato, Ryan Dahl
Today we are releasing Deno 1.6.0. This release contains some major features, and many bug fixes. Here are some highlights:
deno compile
can build your Deno projects into completely standalone
executablesIf 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 cargocargo install deno
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.tsCheck https://deno.land/std@0.79.0/http/file_server.tsBundle https://deno.land/std@0.79.0/http/file_server.tsCompile https://deno.land/std@0.79.0/http/file_server.tsEmit file_server
$ ./file_serverHTTP 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.
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.
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).
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:
deno fmt
integrationdeno lint
integrationThe
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.
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.
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 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.
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.
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.