The only TsConfig you will ever need for backend 🙌

TsConfig is used to configure how typescript behaves in your project, lets see which is the most optimal way to configure it.

Here’s the config which you can just copy and paste to your project, scroll down for the explanations regarding each configuration.

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true
  },
  "include": ["src/**/*"],
  "exclude": ["**/*.test.ts"]
}

Lets deep dive into each config

• dist is where your transpiled code go, in your CICD you only need to copy the dist folder to your server along with package.json to install PROD dependencies.

"outDir": "./dist"

• src is the root folder for your TS code

"rootDir": "./src"

• Following are some strict checks, which will help you in the long run

"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"noImplicitThis": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true

• Decorators, one of the best features of Typescript. most of the awesome frameworks use this, like NestJs, TypeORM, ClassValidator, RoutingControllers, etc. Use the following config to enable decorators

"emitDecoratorMetadata": true,
"experimentalDecorators": true

• Includes the files under src directory

"include": ["src/**/*"]

• Excludes the tests, provide a regex for your test file pattern. Tests are run as TS files before transpiling, we don’t need tests after the transpiration.

"exclude": ["**/*.test.ts"]

Thats all folks, happy hacking 🙌

---

👋 Hey, if you found this article helpful and want to stay updated with my latest tech insights, tips, and tricks, feel free to follow me on Twitter. Let's connect and grow together! 🚀

Comments

[JoelBonetR 🥇]

I've some questions around this:

"target": "es5",
"module": "commonjs",

What's the point on targeting ES5, specially for backend? 😅
Why not use ES instead commonjs?

[Akash Dathan]

I would love to use ES modules and its becoming a standard, and we are getting there but not quite there yet. Since there are some packages still using commonjs I stick to it for now. But hope to move to ES modules in the future.

Also, since we wont read or change the transpiled js, I don't see any advantage on using ES module at the moment, sticking to the most compatible one for now.

[JoelBonetR 🥇]

Sorry, it might be a little of a misconception there, correct me if I'm wrong. Your TSConfig is about how you handle your own dependencies across your software. A third party library that uses CommonJS will have it's own TSConfig (or bundler config) to comply with this and will lead to a given dist that will be treated just as that, but won't -or should not- affect your transpilation. It's the magic of modularity :)

So you may use ES modules without this overhead 😁

On the other side, for frontend is usual to set the target to "ES5", "ES6" or others depending on the browser stack you want/need to support, but for backend it should be the latest stable thingy IMHO (just make sure your RE is the latest stable).

Cheers!

[Akash Dathan]

Yes you are correct, the libraries which we use at runtime should not effect the transpilation. The modules which runs in build time or compliments the code base is the ones which causes issues. one of the example i could think of is the swagger generator. Jest used to have issues earlier, but it works now.

Personally why I stick to commonJS is because of these issues I faced in the past. Writing this, I couldn't think of specific examples, So ill do a boiler plate bootstrap again and see if there are issues still happening and update the post accordingly with my new findings.

Thank you for your input, appreciate it :)

[JoelBonetR 🥇]

That's awesome!

Looking forward to read your findings 😁 please let me know as soon as you publish your data, thank you!

[Nikita Galkin]

1. npm install -D @tsconfig/node18-strictest
2. In tsconfig.json extends @tsconfig/node18-strictest/tsconfig.json
3. Add project specific configuration to your tsconfig.json

Example from real project:

{
  "extends": "@tsconfig/node18-strictest/tsconfig.json",
  "compilerOptions": {
    "allowJs": false,
    "checkJs": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "noEmit": true,
    "baseUrl": ".",
    "paths": {
      "~/*": [
        "./src/*"
      ]
    },
    "ignoreDeprecations": "5.0"
  },
  "include": [
    "src/**/*",
    "tests/**/*"
  ]
}

[Chris Cook]

Take a look at github.com/tsconfig/bases and pick the tsconfig for your node.js version and module format.