DEV Community: Bharath

Beyond Strict Mode: 5 Advanced TSConfig Settings for Bulletproof TypeScript

Bharath — Thu, 28 May 2026 18:07:28 +0000

Most developers believe that setting "strict": true in their tsconfig.json is the ultimate safety net for their codebase. It is a fantastic starting point, but relying on it alone leaves the door wide open for catastrophic type omissions and hidden runtime bugs.

You can have a file completely riddled with type errors without a single warning or red underline from your compiler. To achieve true type safety and completely eliminate silent failures, you need to look beyond strict mode.

These are the 5 highly effective tsconfig.json configurations will harden your type-checking system, catch developer typos before they hit production, and dramatically streamline your development workflow.

1. The Workflow Game-Changer: Path Aliases
2. The Code-Cleaners: Eliminating Dead Weight
3. The Typo-Catchers: Stopping Silent Failures
4. Optional but Highly Recommended Enhancements
5. Personal Preference & Architecture Tuning
6. Seamless JavaScript Migration Settings
Summary Checklist

1. The Workflow Game-Changer: Path Aliases

This first configuration option does not alter type checking, but it fundamentally transforms how you interact with your project's codebase.

The Problem: Relative Import Hell

As a project grows, directory structures naturally deepen. When deep nesting occurs, importing a module from the root or a shared directory turns into a fragile, unreadable mess of relative paths:

// Naive / Problematic Approach
import { RootConfig } from '../../../../../config/root';
import { Button } from '../../../../components/ui/Button';

If you move or copy this file to another directory, every single relative import breaks, forcing a tedious manual reconfiguration.

The Solution: Absolute Imports via paths
By configuring paths in your tsconfig.json, you can define custom absolute alias structures.

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"],
      "@components/*": ["src/components/*"]
    }
  }
}

Note: The baseUrl property must be specified whenever using paths so TypeScript has a benchmark directory to resolve your aliases against.

With this alias map established, your import statements become completely location-agnostic and clean:

// Optimized / Best-Practice Approach
import { RootConfig } from '@/config/root';
import { Button } from '@components/ui/Button';

2. The Code-Cleaners: Eliminating Dead Weight

Unused variables and dead parameters clutter codebases, mask architectural intent, and frequently point to uncompleted refactoring or underlying typos.

{
  "compilerOptions": {
    "noUnusedLocals": true,
    "noUnusedParameters": true
  }
}

noUnusedLocals
When set to true, the compiler flags any local variable declared within your code that is never read or executed.

noUnusedParameters
Similarly, this flags any function or method parameter that goes unused within its respective scope.

// Triggers compiler errors for unused variables and parameters
function calculateTotal(price: number, taxRate: number, discountCode: string): number {
  // Error: 'discountCode' is declared but its value is never read.
  const localTax = price * taxRate; 
  const legacyMarkup = 10; // Error: 'legacyMarkup' is declared but never read.

  return price + localTax;
}

Enabling these options keeps your production code clean, easily human-readable, and free from vestigial variables.

3. The Typo-Catchers: Stopping Silent Failures

These options protect you from esoteric language quirks, silent file resolution issues, and logic holes.

{
  "compilerOptions": {
    "allowUnusedLabels": false,
    "noUncheckedSideEffectImports": true,
    "noFallthroughCasesInSwitch": true,
    "allowUnreachableCode": false
  }
}

allowUnusedLabels
JavaScript has an esoteric, rarely used feature called labels that functions like a structural goto statement. It is a historical pattern that is almost always written by mistake instead of an object literal.

// Naive / Problematic Approach (Valid JS, but highly error-prone)
function createUser() {
  const user = {
    id: 'usr_100'
  };

  // Typo: Intended to assign 'name' inside the user object.
  // Instead, this creates a dangling JavaScript label.
  name: 'John Doe'; 
}

Setting "allowUnusedLabels": false catches this syntax immediately, flagging the mistake as a compile error.

noUncheckedSideEffectImports
Sometimes you need to import a module solely for its side effects (e.g., polyfills, CSS frameworks, global monitoring setups) rather than binding specific components:

import './analytics'; // Side-effect import

By default, if you misspell this filename (e.g., import './analytic'), standard bundlers and TypeScript compilers may fail to throw an explicit error at build time. Enabling noUncheckedSideEffectImports forces TypeScript to actively verify the physical disk existence of side-effect targets, preventing silent deployment failures.

noFallthroughCasesInSwitch
Without explicit termination, switch statement cases cascade sequentially into one another. Unless you intentionally omit break statements to share logic, this behavior yields severe runtime bugs.

// Switch fallthrough error example
type Status = 'success' | 'error' | 'pending';

function handleStatus(status: Status) {
  switch (status) {
    case 'success': // Error: Fallthrough case in switch.
      logSuccess();
      // Missing break statement!
    case 'error':
      logError();
      break;
  }
}

If you intentionally want multiple cases to run the exact same logic block, you can safely structure them consecutively without a body:

// Correct multi-case handling
switch (status) {
  case 'success':
  case 'pending':
    processData(); // Runs for both success and pending
    break;
  case 'error':
    logError();
    break;
}

allowUnreachableCode
Any execution block residing past an explicit return, throw, or break statement can never be reached. Turning "allowUnreachableCode": false helps you proactively sweep away zombie code.

4. Optional but Highly Recommended Enhancements

These advanced settings require small structural changes to how you write your code, but they introduce an unprecedented layer of runtime safety.

{
  "compilerOptions": {
    "noUncheckedIndexAccess": true,
    "noPropertyAccessFromIndexSignature": true
  }
}

noUncheckedIndexAccess
This is one of the most powerful options available in the compiler. Consider an array lookup:

const numbers: number[] = [1, 2, 3];
const tenthElement = numbers[9]; // TypeScript infers this type as 'number' by default
console.log(tenthElement.toFixed()); // Runtime Crash: Cannot read properties of undefined

TypeScript naturally assumes that accessing a valid index of a typed array instantly yields that type. It cannot guess the runtime length of your collection.

Enabling noUncheckedIndexAccess forces every array or index-signature lookup to implicitly append | undefined to the returned type signature:

const numbers: number[] = [1, 2, 3];
const tenthElement = numbers[9]; // Inferred Type: number | undefined

// Error: Object is possibly 'undefined'.
console.log(tenthElement.toFixed()); 

// Optimized / Best-Practice Approach
console.log(tenthElement?.toFixed());

noPropertyAccessFromIndexSignature
When building configuration containers, you often define open-ended index signatures to accept unpredictable developer keys:

type AppSettings = {
  darkMode: boolean;
  [customKey: string]: string | number | boolean;
};

By default, standard dot notation (settings.darkMod) allows arbitrary properties because the object explicitly accepts any key string. This makes it incredibly easy to accidentally introduce a subtle typo on your core settings.

Enabling noPropertyAccessFromIndexSignature explicitly blocks dot notation access for anything not explicitly hard-coded in the type schema:

const settings: AppSettings = { darkMode: true, apiEndpoint: '/v1' };

// Error: Property 'darkMod' does not exist on type 'AppSettings'.
const isDark = settings.darkMod; 

// Accessing dynamic, open-ended entries requires explicit bracket notation
const endpoint = settings['apiEndpoint'];

5. Personal Preference & Architecture Tuning

These configurations adapt to specific architectural preferences, such as Object-Oriented Programming (OOP) paradigms or deep debugging environments.

{
  "compilerOptions": {
    "noImplicitOverride": true,
    "noErrorTruncation": false,
    "exactOptionalPropertyTypes": true
  }
}

noImplicitOverride
If you design your codebase around class inheritance, overriding parent methods without explicit markings can make code maintenance incredibly difficult.

class ViewComponent {
  close() { /* parent logic */ }
}

class ModalWindow extends ViewComponent {
  // Error: This member must have an 'override' modifier 
  // because it overrides a member in the base class 'ViewComponent'.
  close() { /* child logic */ } 
}

Adding the explicit keyword ensures that your architectural intent is clear and protected:

class ModalWindow extends ViewComponent {
  override close() { /* child logic */ }
}

noErrorTruncation
When dealing with deeply nested generics or complex utility frameworks (like Zod, Drizzle, or TanStack Query), TypeScript's error tooltips can become incredibly long. By default, the compiler cuts these messages off with an ellipsis (...).

Setting "noErrorTruncation": true instructs the compiler to print out the full, unabridged type structure inside error logs.

Tip: Keep this disabled by default to avoid overwhelming error blocks, and toggle it on temporarily only when diagnosing complex type puzzles.

exactOptionalPropertyTypes
In vanilla JavaScript, an optional property is structurally ambiguous. There is a distinct difference between a property being omitted entirely and a property being explicitly set to undefined.

type UserProfile = {
  bio?: string;
};

// Without exactOptionalPropertyTypes, both are allowed:
const userA: UserProfile = {}; // bio is missing
const userB: UserProfile = { bio: undefined }; // bio exists, holding undefined value

Why does this distinction matter? Operators like 'bio' in user yield completely different boolean values depending on whether the key exists. Turning on exactOptionalPropertyTypes enforces strict precision: an optional property can be omitted, but it cannot be explicitly assigned undefined.

6. Seamless JavaScript Migration Settings

If you are migrating an older JavaScript application to TypeScript, changing your whole project overnight is rarely an option. These tools enable a gradual, file-by-file adoption process.

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false
  }
}

allowJs
Instructs the TypeScript engine to parse and import plain .js files alongside your native .ts structures instead of throwing immediate import resolution errors.

checkJs
When turned on globally, TypeScript applies its full type-checking logic to your legacy JavaScript modules using inferred type algorithms and JSDoc declarations.

Recommended Migration Strategy
Rather than enabling checkJs globally and instantly generating thousands of errors across an enterprise app, leave "checkJs": false in your master config. Instead, append the // @ts-check directive to the very top line of individual JavaScript files as you refactor them:

// @ts-check
import { parseAmount } from './utils';

// TypeScript checks this file and catches the incorrect type assignment!
// Error: Argument of type 'number' is not assignable to parameter of type 'string'.
parseAmount(1250);

Summary Checklist

Here is a look at a comprehensive, high-security tsconfig.json template ready to drop into your root directory:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,                 /* The baseline foundation */

    /* Absolute Path Maps */
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"]
    },

    /* Code Cleaners */
    "noUnusedLocals": true,
    "noUnusedParameters": true,

    /* Typo Prevention & Logic Safeguards */
    "allowUnusedLabels": false,
    "noUncheckedSideEffectImports": true,
    "noFallthroughCasesInSwitch": true,
    "allowUnreachableCode": false,

    /* Advanced Type Safety Rules */
    "noUncheckedIndexAccess": true,
    "noPropertyAccessFromIndexSignature": true,
    "exactOptionalPropertyTypes": true,

    /* Code Consistency */
    "noImplicitOverride": true
  }
}

Final Thoughts 💡

What would be your approach ?

Are you already running strict rules like noUncheckedIndexAccess in your current applications, or are you about to add them to your configurations for the first time? If you have a favorite compiler flag that saved your code from a production incident, drop a comment below!

If you find errors in this article please drop a comment too. Thanks for your time !

To Level Up Your React Workflow: 3 Essential VS Code Basic Extensions Every Web Developer Needs to Use

Bharath — Fri, 15 May 2026 10:50:12 +0000

If you are a React developer, your productivity is heavily influenced by your tools. While VS Code is powerful out of the box, the right extensions can transform it from a simple text editor into a high-performance IDE tailored for modern web development.

To take your coding experience to the next level, here are three "must-have" VS Code extensions that will save you hours of debugging and boilerplate typing.

1. Tailwind CSS IntelliSense 🎨

Tailwind CSS has become the industry standard for styling modern React applications. However, remembering every single utility class can be a challenge.

Why you need it:

Auto-Suggestions: As you start typing a class name, it provides a dropdown of available Tailwind utilities.
Color Previews: No more guessing what bg-t looks like. A small color swatch appears right in your gutter or next to the code.
Faster Coding: It reduces the need to constantly flip back and forth between your code and the Tailwind documentation.

2. ES7+ React/Redux/React-Native Snippets ⚡

Stop writing export default function... manually every single time you create a new file. This extension is a massive time-saver for repetitive React patterns.

The Power Move:
After installing this, you can simply type a short command like rafce (React Arrow Function Component Export) and hit Enter.

Result: It instantly generates a full, boilerplate-ready React component with imports and exports included. Whether you are working on hooks, Redux, or React Native, these snippets make your development cycle significantly faster.

3. ESLint 🔍

Writing code is easy; maintaining clean, bug-free code is the hard part. ESLint is your first line of defense against "silly" mistakes that break your build.

Why you need it:

Error Detection: It highlights potential bugs and syntax errors in real-time with red underlines before you even save the file.
Clean Code Standards: It enforces consistent coding styles across your project, ensuring your code remains professional and readable.
Auto-Fixing: Many common linting errors can be fixed automatically on save, keeping your focus on logic rather than formatting.

Final Thoughts 💡

By integrating Tailwind CSS IntelliSense, ES7+ Snippets, and ESLint into your VS Code setup, you aren't just coding—you're coding smarter. These tools eliminate friction, reduce errors, and allow you to focus on building amazing user experiences.

What’s your favorite VS Code extension for React? Let me know in the comments below! 👇

Gist of SSL/mTLS

Bharath — Tue, 16 Dec 2025 12:33:31 +0000

Objective of writing down this post is to just recollect the concept overview of mTLS and to easy in explaining to any new intern in order to enable for kafka or other system.

Secure Sockets Layer (SSL)

SSL is a protocol that is used to protect communication between clients and servers over the Internet.
SSL provides such features as server authentication, client authentication, and data encryption. Authentication confirms the identity of a server or client. Encryption converts data into an unreadable form before the data is sent.
The scheme of a URL that uses SSL is https. For example:

https://dev.to/

The latest version of SSL is called Transport Layer Security (TLS). The Internet Engineering Task Force (IETF) maintains the TLS standard.

What is TLS?
Transport Layer Security (TLS) is an encryption protocol in wide use on the Internet. TLS, which was formerly called SSL, authenticates the server in a client-server connection and encrypts communications between client and server so that external parties cannot spy on the communications.

Normally in TLS, the server has a TLS certificate and a public/private key pair, while the client does not.

There are 3 important things to understand about how TLS works:

Public key and private key
To perform authentication, TSL uses a technique called public-key cryptography.
Public-key cryptography is based on the concept of a key pair, which consists of a public key and a private key. Data that has been encrypted with a public key can be decrypted only with the corresponding private key. Conversely, data that has been encrypted with a private key can be decrypted only with the corresponding public key.
The owner of the key pair makes the public key available to anyone, but keeps the private key secret.
we can use two tools for generation of this key pair
- Keytool
  
  The keytool program is a security tool included in the bin directory of the JavaTM SDK.
- OpenSSL
  
  The OpenSSL Project is an effort to develop an open-source toolkit that implements the SSL and TLS protocols, as well as a cryptographic library.The toolkit includes the openssl command-line tool, which enables you to use various functions of the cryptographic library.
TLS certificate
A TLS certificate is a data file that contains important information for verifying a server's or device's identity, including the public key, a statement of who issued the certificate (TLS certificates are issued by a certificate authority), and the certificate's expiration date.
You can obtain a certificate from a Certificate Authority (CA) such as VeriSign. Alternately, you can create a self-signed certificate, in which the owner and the issuer are the same.
An organization that issues certificates can establish a hierarchy of CAs. The root CA has a self-signed certificate. Each subordinate CA has a certificate that is signed by the next highest CA in the hierarchy. A certificate chain is the certificate of a particular CA, plus the certificates of any higher CAs up through the root CA.
TLS handshake
A TLS handhsake process works like below
1. Client connects to server
2. Server presents its TLS certificate
3. Client verifies the server's certificate
4. Client and server exchange information over encrypted TLS connection

Mutual TLS (mTLS)

Mutual TLS or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.

mTLS is often used in a Zero Trust security framework to verify users, devices, and servers within an organization.

Zero Trust means that no user, device, or network traffic is trusted by default, an approach that helps eliminate many security vulnerabilities.

In mTLS, both the client and server have a certificate, and both sides authenticate using their public/private key pair.

The mTLS handhsake process works like below
1. Client connects to server
2. Server presents its TLS certificate
3. Client verifies the server's certificate
4. Client presents its TLS certificate
5. Server verifies the client's certificate
6. Server grants access
7. Client and server exchange information over encrypted TLS connection

Why use mTLS when we already use TLS?

TLS is one-way authentication in which the client verifies the server's identity only which provide protection like ensure not spoofed websites, keep private data secure and encrypted as it crosses the various networks that comprise the Internet and to make sure that data is not altered in transit

where as mTLS helps ensure that traffic is secure and trusted in both directions between a client and server. mTLS provides additional protection by preventing various kinds of attacks like

On-path attacks
Spoofing attacks
Credential stuffing
Brute force attacks
Phishing attacks
Malicious API requests

How to Setup mTLS

A setup a mTLS we need to follow couple of below steps

Generate a private key (RSA or EC)
Generate CSR → send to CA.
Get it signed by a CA (or create a self‑signed cert for tests) CA issues CRT/CER → your certificate.
Assemble the certificate chain (server cert + intermediate(s) + root).
Store private key + cert chain into a PKCS#12 or JKS Keystore.
Convert formats if needed (PEM ↔ PKCS12 ↔ JKS).
Truststore holds CA certs to validate incoming connections.
Verify with OpenSSL and keytool.

KeyStores

keystore stores private key entries, certificates with public keys, or just secret keys that we may use for various cryptographic purposes. It stores each by an alias for ease of lookup.

Generally speaking, keystores hold keys that our application owns, which we can use to prove the integrity of a message and the authenticity of the sender, say by signing payloads.

Usually, we’ll use a keystore when we’re a server and want to use HTTPS. During an SSL handshake, the server looks up the private key from the keystore, and presents its corresponding public key and certificate to the client.

TrustStores

A truststore is the opposite. While a keystore typically holds onto certificates that identify us, a truststore holds onto certificates that identify others.

In Java, we use it to trust the third party we’re about to communicate with.

Take our earlier example. If a client talks to a Java-based server over HTTPS, the server will look up the associated key from its keystore and present the public key and certificate to the client.

We, the client, then look up the associated certificate in our truststore. If the certificate or Certificate Authorities presented by the external server isn’t in our truststore, we’ll get an SSLHandshakeException, and the connection won’t be set up successfully.
Java has bundled a truststore called cacerts. For Java versions before 9, it resides in the $JAVA_HOME/jre/lib/security directory, and for Java versions after 8, it’s in $JAVA_HOME/lib/security. It contains default, trusted Certificate Authorities.

CSR (Certificate Signing Request)

A CSR (.csr, .req) is a Certificate Signing Request is a file that you create and send to Certificate Authority (CA) when you want an SSL/TLS certificate from a CA. It’s like an application form for a certificate.
What it contains: Your public key + details like domain name, organization.

CER / CRT (Certificate)

A file that holds the actual certificate issued by a CA after verifying your CSR.
CER vs CRT: Both are certificate files, just different extensions (often .cer or .crt).
What it Contains: Your public key + metadata + CA signature.

PEM

A text-based file format (Base64 encoded) for certificates and keys.
What it contains: Often used to store CSR, CRT, private key or both.

PKCS12 (.p12 or .pfx)

A bundle format that can include certificate + private key + chain in one file. Easy to transport and import into systems/applications.
You create this after you have your certificate and private key.

How to generate
Will cover the detailed steps to generate the using keytool and openssl in another follow up post. To be continued

Content in this post is extracted from different sources of internet.

DEV Community: Bharath

Beyond Strict Mode: 5 Advanced TSConfig Settings for Bulletproof TypeScript

Table of Contents

1. The Workflow Game-Changer: Path Aliases

The Problem: Relative Import Hell

2. The Code-Cleaners: Eliminating Dead Weight

3. The Typo-Catchers: Stopping Silent Failures

4. Optional but Highly Recommended Enhancements

5. Personal Preference & Architecture Tuning

6. Seamless JavaScript Migration Settings

Summary Checklist

Final Thoughts 💡

To Level Up Your React Workflow: 3 Essential VS Code Basic Extensions Every Web Developer Needs to Use

1. Tailwind CSS IntelliSense 🎨

2. ES7+ React/Redux/React-Native Snippets ⚡

3. ESLint 🔍

Final Thoughts 💡

Gist of SSL/mTLS

Secure Sockets Layer (SSL)

Mutual TLS (mTLS)

Why use mTLS when we already use TLS?

How to Setup mTLS

KeyStores

TrustStores

CSR (Certificate Signing Request)

CER / CRT (Certificate)

PEM

PKCS12 (.p12 or .pfx)