That being said, Deno does support using a TypeScript configuration file, though like the rest of Deno, the detection and use of use of a configuration file is not automatic. To use a TypeScript configuration file with Deno, you have to provide a path on the command line. For example:

Deno does not process a TypeScript configuration file like does, as there are lots of parts of a TypeScript configuration file that are meaningless in a Deno context or would cause Deno to not function properly if they were applied.

Here is a table of compiler options that can be changed, their default in Deno and any other notes about that option:

For a full list of compiler options and how they affect TypeScript, please refer to the

It is impossible to get tsc to behave like Deno. It is also difficult to get the TypeScript language service to behave like Deno. This is why we have built a language service directly into Deno. That being said, it can be useful to understand what is implied.

{
  "compilerOptions": {
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "inlineSourceMap": true,
    "isolatedModules": true,
    "jsx": "react",
    "module": "esnext",
    "strict": true,
    "target": "esnext",
    "useDefineForClassFields": true
  }

You can’t copy paste this into a tsconfig.json and get it to work, specifically because of the built in type libraries that are custom to Deno which are provided to the TypeScript compiler. This can somewhat be mocked by running deno types on the command line and piping the output to a file and including that in the files as part of the program, removing the "lib" option, and setting the "noLib" option to true.

If you use the --unstable flag, Deno will change the "lib" option to [ "deno.window", "deno.unstable" ]. If you are trying to load a worker, that is type checked with "deno.worker" instead of "deno.window".

[TBC]