But wait a minute, does Deno really run TypeScript? you might be asking yourself. Well, depends on what you mean by run. One could argue that in a browser you don’t actually run JavaScript either. The JavaScript engine in the browser translates the JavaScript to a series of operation codes, which it then executes in a sandbox. So it translates JavaScript to something close to assembly. Even Web Assembly goes through a similar translation, in that Web Assembly is architecture agnostic while it needs to be translated into the machine specific operation codes needed for the particular platform architecture it is running on. So when we say TypeScript is a first class language in Deno, we mean that we try to make the user experience in authoring and running TypeScript as easy and straightforward as JavaScript and Web Assembly.

Behind the scenes, we use a combination of technologies, in Rust and JavaScript, to provide that experience.

At a high level, Deno converts TypeScript (as well as TSX and JSX) into JavaScript. It does this via a combination of the , which we build into Deno, and a Rust library called swc. When the code has been type checked and transformed, it is stored in a cache, ready for the next run without the need to convert it from its source to JavaScript again.

You can see this cache location by running :

If you were to look in that cache, you would see a directory structure that mimics that source directory structure and individual .js and .meta files (also potentially .map files). The .js file is the transformed source file while the .meta file contains meta data we want to cache about the file, which at the moment contains a hash of the source module that helps us manage cache invalidation. You might also see a .buildinfo file as well, which is a TypeScript compiler incremental build information file, which we cache to help speed up type checking.

Type Checking

In Deno we handle TypeScript in two major ways. We can type check TypeScript, the default, or you can opt into skipping that checking using the --no-check flag. For example if you had a program you wanted to run, normally you would do something like this:

But if you wanted to skip the type checking, you would do something like this:

Type checking can take a significant amount of time, especially if you are working on a code base where you are making a lot of changes. We have tried to optimise the type checking, but it still comes at a cost. If you just want to hack at some code, or if you are working in an IDE which is type checking your code as you author it, using --no-check can certainly speed up the process of running TypeScript in Deno.

Since Deno supports JavaScript, TypeScript, JSX, TSX modules, Deno has to make a decision about how to treat each of these kinds of files. For local modules, Deno makes this determination based fully on the extension. When the extension is absent in a local file, it is assumed to be JavaScript.

For remote modules, the media type (mime-type) is used to determine the type of the module, where the path of the module is used to help influence the file type, when it is ambiguous what type of file it is.

Supported media types

The following table provides a list of media types which Deno supports when identifying the type of file of a remote module:

Strict by default

Deno type checks TypeScript in strict mode by default, and the TypeScript core team recommends strict mode as a sensible default. This mode generally enables features of TypeScript that probably should have been there from the start, but as TypeScript continued to evolve, would be breaking changes for existing code.

By default, Deno does not type check JavaScript. This can be changed, and is discussed further in Configuring TypeScript in Deno. Deno does support JavaScript importing TypeScript and TypeScript import JavaScript, in complex scenarios.

An important note though is that when type checking TypeScript, by default Deno will “read” all the JavaScript in order to be able to evaluate how it might have an impact on the TypeScript types. The type checker will do the best it can to figure out what the types are of the JavaScript you import into TypeScript, including reading any JSDoc comments. Details of this are discussed in detail in the section.

Diagnostics are terminal

While tsc by default will still emit JavaScript when run while encountering diagnostic (type checking) issues, Deno currently treats them as terminal. It will halt on these warnings, not cache any of the emitted files, and exit the process.

One of the core design principles of Deno is to avoid “magical” resolution, and this applies to type resolution as well. If you want to utilise JavaScript that has type definitions (e.g. a .d.ts file), you have to explicitly tell Deno about this. The details of how this is accomplished are covered in the section.