Also, in recent versions of Deno (starting with 1.5), we have started to use a Rust library to do transformations of TypeScript to JavaScript in certain scenarios. Because of this, there are certain situations in TypeScript where type information is required, and therefore those are not supported under Deno. If you are using as stand-alone, the setting to use is "isolatedModules" and setting it to true to help ensure that your code can be properly handled by Deno.

One of the ways to deal with the extension and the lack of magical resolution is to use which would allow you to specify “packages” of bare specifiers which then Deno could resolve and load.

What version(s) of TypeScript does Deno support?

Deno is built with a specific version of TypeScript. To find out what this is, type the following on the command line:

The TypeScript version (along with the version of Deno and v8) will be printed. Deno tries to keep up to date with general releases of TypeScript, providing them in the next patch or minor release of Deno.

In addition you can utilize @ts-ignore to ignore a specific error in code that you control. You can also replace whole dependencies, using , for situations where a dependency of a dependency isn’t being maintained or has some sort of breaking change you want to bypass while waiting for it to be updated.

Why are you forcing me to use isolated modules, why can’t I use const enums with Deno, why do I need to do export type?

As of Deno 1.5 we defaulted to isolatedModules to true and in Deno 1.6 we removed the options to set it back to false via a configuration file. The isolatedModules option forces the TypeScript compiler to check and emit TypeScript as if each module would stand on its own. TypeScript has a few type directed emits in the language at the moment. While not allowing type directed emits into the language was a design goal for TypeScript, it has happened anyways. This means that the TypeScript compiler needs to understand the erasable types in the code to determine what to emit, which when you are trying to make a fully erasable type system on top of JavaScript, that becomes a problem.

When people started transpiling TypeScript without , these type directed emits became a problem, since the likes of Babel simply try to erase the types without needing to understand the types to direct the emit. In the internals of Deno we have started to use a Rust based emitter which allows us to optionally skip type checking and generates the bundles for things like deno bundle. Like all transpilers, it doesn’t care about the types, it just tries to erase them. This means in certain situations we cannot support those type directed emits.

So instead of trying to get every user to understand when and how we could support the type directed emits, we made the decision to disable the use of them by forcing the isolatedModules option to true. This means that even when we are using the TypeScript compiler to emit the code, it will follow the same “rules” that the Rust based emitter follows.

• Re-exporting of types is ambigious and requires to know if the source module is exporting runtime code or just type information. Therefore, it is recommended that you use import type and export type for type only imports and exports. This will help ensure that when the code is emitted, that all the types are erased.
• const enum is not supported. const enums require type information to direct the emit, as s get written out as hard coded values. Especially when const enums get exported, they are a type system only construct.
• Only declare namespace is support. Runtime namespace is legacy TypeScript syntax that is not supported.

While tsc supports language service plugins, Deno does not. Deno does not always use the built in TypeScript compiler to do what it does, and the complexity of adding support for a language service plugin is not feasible. TypeScript does not support emitter plugins, but there are a few community projects which hack emitter plugins into TypeScript. First, we wouldn’t want to support something that TypeScript doesn’t support, plus we do not always use the TypeScript compiler for the emit, which would mean we would need to ensure we supported it in all modes, and the other emitter is written in Rust, meaning that any emitter plugin for TypeScript wouldn’t be available for the Rust emitter.

The TypeScript in Deno isn’t intended to be a fully flexible TypeScript compiler. Its main purpose is to ensure that TypeScript and JavaScript can run under Deno. The secondary ability to do TypeScript and JavaScript emitting via the runtime API is intended to be simple and straight forward and support a certain set of use cases.

How do I combine Deno code with non-Deno code in my IDE?

The Deno language server supports the ability to have a “per-resource” configuration of enabling Deno or not. This also requires a client IDE to support this ability. For Visual Studio Code the official Deno extension supports the vscode concept of . This means you just need to add folders to the workspace and set the deno.enable setting as required on each folder.

For other IDEs, the client extensions needs to support the similar IDE concepts.