Sign Up for Free

RunKit +

Try any Node.js package right in your browser

This is a playground to test code. It runs a full Node.js environment and already has all of npm’s 400,000 packages pre-installed, including tsconfigs with all npm packages installed. Try it out:

tsconfigs lists no main file and has no index.js, so it can't be directly required. If this is a mistake, please let us know. It may however contain internal files that you can require manually:

// require("tsconfigs/[??]")

This service is provided by RunKit and is not affiliated with npm, Inc or the package authors.

tsconfigs v5.0.0

Reusable TypeScript configuration files to extend from.

⚙️ tsconfigs ✨

Renovate enabled Build Status Badge: npm version badge for package

Reusable TypeScript configuration files

## Contents

Overview

Say you're starting a new TypeScript project. And you're setting up the tsconfig.json. If you're a TypeScript wizard 🧙‍ you quickly fill in some options and you're done. But If you're a meer mortal like most of us, you go back to the documentation every time 🤔. After several times of that I decided to write this little project 💡.

If your project is one of the following kinds of projects, you could extend from one of them, instead of writing your own from blank. And then you could override any options necessary.

Project kinds

Module ⚙️Executable 🚄
Browser 🌐browser-modulebrowser-executable
Web Worker ⛏️webworker-module
Node.js ⬡nodejs-modulenodejs-executable
Agnostic 🏳️agnostic-module

Example

Install this package (tsconfigs) and in your tsconfig.json:

{
  "extends": "tsconfigs/nodejs-executable", // 🎆
  "compilerOptions": {
    "outDir": "lib"
  },
  "include": [
    "src/**/*"
  ]
}

Scope

Executable project options

OptionDefault valueOur valueComment
compositetruefalseIt seems to have no benefit for executables and it necessitates generation of declaration files, which seem useless in executables, as well.

Module project options

OptionDefault valueOur valueComment
declarationfalsetrueBecause we'd like to provide the importer with type definitions.

Environment

Browser project options

OptionDefault valueOur value
libdepends["ESNext","DOM"]
moduledepends"ESNext"

Web Worker project options

OptionDefault valueOur value
libdepends["ESNext","WebWorker"]
moduledepends"ESNext"

Node.js project options

OptionDefault valueOur valueComment
libdepends["ESNext"].You'd most likely also like to install the @types/node package.
moduledepends"CommonJS"

Agnostic project options

OptionDefault valueOur valueComment
libdepends["ESNext"]
moduledepends"CommonJS"While for small packages, CommonJS could be just fine, for larger packages, where the ability to perform tree shaking is desirable, it seems that the agnostic project author should consider providing two builds. One CommonJS build and one ES modules build.

Common project options

OptionDefault valueOur valueComment
allowSyntheticDefaultImportsdependstrueStack Overflow question
esModuleInteropfalsetrueStack Overflow question
forceConsistentCasingInFileNamesfalsetrueWhile it does not enforce case sensitivity, it at least enforces consistent casing across references.
moduleResolutiondepends"node"The de-facto standard.
newLinedepends"LF"For the sake of consistent build artifacts cross-platform.
noErrorTruncationfalsetrueScreenshots: false / true
resolveJsonModulefalsetrueSeems like a popular feature that does not involve drawbacks.
sourceMapfalsetrueWe have chosen regular source maps because it seems like the simple choice that would serve most projects.
strictfalsetrueSee Strictness.
target"es3""esnext"Down-transpilation is outside the scope of this project. Also, consider using Babel instead of TypeScript for that.

Strictness

We presume that strict type checking is generally desirable.

New type checking features in future releases of TypeScript are, per policy, turned off by default, for backward compatibility. Effectively making new type features, opt-in.

The strict option, however, turns on a set of strict type checking options. New strict options from future TypeScript releases will be included in it, effectively making new type checking features opt-out.

tsconfigs maintains the opt-out behavior: we turn strict on and yet keep the individual type check options that it includes, off.

Paths

We would love to include some path options like include and outDir but we feel that it would not be reliable, because TypeScript resolves relative paths from the configuration file in which they appear and not from the end-configuration file. See this issue.

Test coverage

There are both unit and integration tests for each config.

RunKit is a free, in-browser JavaScript dev environment for prototyping Node.js code, with every npm package installed. Sign up to share your code.
Sign Up for Free