This can cause a couple problems though. For example, let’s say I want to consume a TypeScript file that has already been transpiled to JavaScript along with a type definition file. So I have mod.js and mod.d.ts. If I try to import mod.js into Deno, it will only do what I ask it to do, and import mod.js, but that means my code won’t be as well type checked as if TypeScript was considering the mod.d.ts file in place of the mod.js file.

In order to support this in Deno, Deno has two solutions, of which there is a variation of a solution to enhance support. The two main situations you come across would be:

• As the importer of a JavaScript module, I know what types should be applied to the module.
• As the supplier of the JavaScript module, I know what types should be applied to the module.

The latter case is the better case, meaning you as the provider or host of the module, everyone can consume it without having to figure out how to resolve the types for the JavaScript module, but when consuming modules that you may not have direct control over, the ability to do the former is also required.

If you are consuming a JavaScript module and you have either created types (a .d.ts file) or have otherwise obtained the types, you want to use, you can instruct Deno to use that file when type checking instead of the JavaScript file using the @deno-types compiler hint. @deno-types needs to be a single line double slash comment, where when used impacts the next import or re-export statement.

For example if I have a JavaScript modules coolLib.js and I had a separate coolLib.d.ts file that I wanted to use, I would import it like this:

When type checking coolLib and your usage of it in the file, the coolLib.d.ts types will be used instead of looking at the JavaScript file.

The pattern matching for the compiler hint is somewhat forgiving and will accept quoted and non-question values for the specifier as well as it accepts whitespace before and after the equals sign.

Providing types when hosting

If you are in control of the source code of the module, or you are in control of how the file is hosted on a web server, there are two ways to inform Deno of the types for a given module, without requiring the importer to do anything special.

Using the triple-slash reference directive

Deno supports using the triple-slash reference types directive, which adopts the reference comment used by TypeScript in TypeScript files to include other files and applies it only to JavaScript files.

For example, if I had created coolLib.js and along side of it I had created my type definitions for my library in coolLib.d.ts I could do the following in the coolLib.js file:

/// <reference types="./coolLib.d.ts" />
// ... the rest of the JavaScript ...

When Deno encounters this directive, it would resolve the ./coolLib.d.ts file and use that instead of the JavaScript file when TypeScript was type checking the file, but still load the JavaScript file when running the program.

Using X-TypeScript-Types header

Similar to the triple-slash directive, Deno supports a header for remote modules that instructs Deno where to locate the types for a given module. For example, a response for https://example.com/coolLib.js might look something like this:

HTTP/1.1 200 OK
Content-Type: application/javascript; charset=UTF-8
Content-Length: 648

Overall it is better to use module/UMD type definitions with Deno, where a module expressly imports the types it depends upon. Modular type definitions can express augmentation of the global scope via the declare global in the type definition. For example:

This would make AGlobalString available in the global namespace when importing the type definition.

In some cases though, when leveraging other existing type libraries, it may not be possible to leverage modular type definitions. Therefore there are ways to include arbitrary type definitions when type checking programmes.

Using a triple-slash directive

This option couples the type definitions to the code itself. By adding a triple-slash types directive near the type of a module, type checking the file will include the type definition. For example:

/// <reference types="./types.d.ts" />

The specifier provided is resolved just like any other specifier in Deno, which means it requires an extension, and is relative to the module referencing it. It can be a fully qualified URL as well:

/// <reference types="https://deno.land/x/pkg@1.0.0/types.d.ts" />

Using a configuration file

Another option is to use a configuration file that is configured to include the type definitions, by supplying a "types" value to the "compilerOptions". For example:

Like the triple-slash reference above, the specifier supplied in the "types" array will be resolved like other specifiers in Deno. In the case of relative specifiers, it will be resolved relative to the path to the config file. Make sure to tell Deno to use this file by specifying --config=path/to/file flag.

Type Checking Web Workers

When Deno loads a TypeScript module in a web worker, it will automatically type check the module and its dependencies against the Deno web worker library. This can present a challenge in other contexts like deno cache, deno bundle, or in editors. There are a couple of ways to instruct Deno to use the worker libraries instead of the standard Deno libraries.

Using triple-slash directives

This option couples the library settings with the code itself. By adding the following triple-slash directives near the top of the entry point file for the worker script, Deno will now type check it as a Deno worker script, irrespective of how the module is analyzed:

/// <reference no-default-lib="true" />

The first directive ensures that no other default libraries are used. If this is omitted, you will get some conflicting type definitions, because Deno will try to apply the standard Deno library as well. The second instructs Deno to apply the built in Deno worker type definitions plus dependent libraries (like "esnext").

When you run a deno cache or deno bundle command or use an IDE which uses the Deno language server, Deno should automatically detect these directives and apply the correct libraries when type checking.

The one disadvantage of this, is that it makes the code less portable to other non-Deno platforms like tsc, as it is only Deno which has the "deno.worker" library built into it.

Using a configuration file

Another option is to use a configuration file that is configured to apply the library files. A minimal file that would work would look something like this:

{
  "compilerOptions": {
    "target": "esnext",
    "lib": ["deno.worker"]
  }
}

If you also have non-worker scripts, you will either need to omit the --config argument, or have one that is configured to meet the needs of your non-worker scripts.

Type declaration semantics

Type declaration files (.d.ts files) follow the same semantics as other files in Deno. This means that declaration files are assumed to be module declarations (UMD declarations) and not ambient/global declarations. It is unpredictable how Deno will handle ambient/global declarations.

In addition, if a type declaration imports something else, like another .d.ts file, its resolution follow the normal import rules of Deno. For a lot of the .d.ts files that are generated and available on the web, they may not be compatible with Deno.

To overcome this problem, some solution providers, like the , will automatically bundle type declarations just like they provide bundles of JavaScript as ESM.

Deno Friendly CDNs

There are CDNs which host JavaScript modules that integrate well with Deno.

• is a CDN which provides type declarations (via the X-TypeScript-Types header) when you append ?dts as a query string to your remote module import statements. For example:

Behavior of JavaScript when type checking

If you import JavaScript into TypeScript in Deno and there are no types, even if you have checkJs set to false (the default for Deno), the TypeScript compiler will still access the JavaScript module and attempt to do some static analysis on it, to at least try to determine the shape of the exports of that module to validate the import in the TypeScript file.

This is usually never a problem when trying to import a “regular” ES module, but in some cases if the module has special packaging, or is a global UMD module, TypeScript’s analysis of the module can fail and cause misleading errors. The best thing to do in this situation is provide some form of types using one of the methods mention above.

Internals

While it isn’t required to understand how Deno works internally to be able to leverage TypeScript with Deno well, it can help to understand how it works.

Before any code is executed or compiled, Deno generates a module graph by parsing the root module, and then detecting all of its dependencies, and then retrieving and parsing those modules, recursively, until all the dependencies are retrieved.

For each dependency, there are two potential “slots” that are used. There is the code slot and the type slot. As the module graph is filled out, if the module is something that is or can be emitted to JavaScript, it fills the code slot, and type only dependencies, like .d.ts files fill the type slot.

When the module graph is built, and there is a need to type check the graph, Deno starts up the TypeScript compiler and feeds it the names of the modules that need to be potentially emitted as JavaScript. During that process, the TypeScript compiler will request additional modules, and Deno will look at the slots for the dependency, offering it the type slot if it is filled before offering it the code slot.

This means when you import a module, or you use one of the solutions above to provide alternative type modules for JavaScript code, that is what is provided to TypeScript instead when resolving the module.