Shareable TypeScript configuration files to extend from
source link: https://github.com/mightyiam/tsconfigs
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
⚙️ tsconfigs :sparkles:
Reusable TypeScript configuration files
Contents
-
- Executable project options
- Module project options
-
- Browser project options
- Web Worker project options
- Node.js project options
- Agnostic project options
- Common project options
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 :bulb:
.
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
Executable :bullettrain_side:
Browser :globe_with_meridians:
browser-module
browser-executable
webworker-module
nodejs-module
nodejs-executable
agnostic-module
Example
Install this package (
tsconfigs
) and in your tsconfig.json
:
{ "extends": "tsconfigs/nodejs-executable", // :fireworks: "compilerOptions": { "outDir": "lib" }, "include": [ "src/**/*" ] }
Scope
Executable project options
Option Default value Our value Commentcomposite
true
false
It seems to have no benefit for executables and it necessitates generation of declaration files, which seem useless in executables, as well.
Module project options
Option Default value Our value Commentdeclaration
false
true
Because we'd like to provide the importer with type definitions.
Environment
Browser project options
Option Default value Our valuelib
depends
["ESNext","DOM"]
module
depends
"ESNext"
Web Worker project options
Option Default value Our valuelib
depends
["ESNext","WebWorker"]
module
depends
"ESNext"
Node.js project options
Option Default value Our value Commentlib
depends
["ESNext"]
.
You'd most likely also like to install the
@types/node
package
.
module
depends
"CommonJS"
Agnostic project options
Option Default value Our value Commentlib
depends
["ESNext"]
module
depends
"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
Option Default value Our value CommentallowSyntheticDefaultImports
depends
true
Stack Overflow question
esModuleInterop
false
true
Stack Overflow question
forceConsistentCasingInFileNames
false
true
While it does not enforce case sensitivity, it at least enforces consistent casing across references.
moduleResolution
depends
"node"
The de-facto standard.
newLine
depends
"LF"
For the sake of consistent build artifacts cross-platform.
noErrorTruncation
false
true
Screenshots:
false
/
true
resolveJsonModule
false
true
Seems like a popular feature that does not involve drawbacks.
sourceMap
false
true
We have chosen regular source maps because it seems like the simple choice that would serve most projects.
strict
false
true
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 .
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK