DEV Community: Krunal Kanojiya

How to Use Type Annotations to Explicitly Type Variables in TypeScript

Krunal Kanojiya — Fri, 12 Jun 2026 02:21:11 +0000

TLDR

A type annotation tells TypeScript exactly what type a variable, function parameter, or return value should be. You write it using a colon after the name, like let age: number = 30. Annotations are removed when TypeScript compiles to JavaScript. They only exist to help you catch bugs during development.

What is a Type Annotation?

A type annotation is a label you attach to a variable or function. It tells TypeScript what kind of value is allowed there.

TypeScript can guess types in many situations on its own. But sometimes it cannot. And sometimes you want to be extra clear about what a variable should hold. That is when you write an annotation yourself.

The syntax is simple. You put a colon after the name, then write the type:

let age: number;
let name: string;
let isActive: boolean;

The Basic Syntax

The pattern for a type annotation is always the same:

name: type

You can add it to variables, constants, function parameters, and return values. Here is the syntax for each:

Where	Syntax	Example
Variable	`let name: type`	`let score: number`
Constant	`const name: type = value`	`const title: string = "Admin"`
Function parameter	`(param: type)`	`(age: number)`
Function return value	`(): type`	`(): string`
Array	`name: type[]`	`let tags: string[]`
Object	`name: { key: type }`	`let user: { name: string }`

How to Annotate Variables

The most common place to use annotations is on variables declared with let.

let username: string;
let score: number;
let isLoggedIn: boolean;

Here, the variables are declared but not given a value yet. TypeScript knows their types from the annotation alone.

Later, when you assign a value, TypeScript checks that it matches:

username = "Alice";    // OK
username = 42;         // Error: Type 'number' is not assignable to type 'string'.

score = 100;           // OK
score = "one hundred"; // Error: Type 'string' is not assignable to type 'number'.

You can also annotate and assign a value in one line:

let username: string = "Alice";
let score: number = 100;
let isLoggedIn: boolean = true;

Annotating constants

const variables cannot be reassigned. You can still annotate them, but it is often not needed because TypeScript infers the type from the value.

const MAX_RETRIES: number = 3;    // Annotation added for clarity
const API_URL: string = "https://api.example.com";
const DEBUG: boolean = false;

How to Annotate Function Parameters

Function parameters are the most important place to add type annotations. Without them, TypeScript cannot check if you call the function with the wrong values.

function greet(name: string): void {
  console.log("Hello, " + name);
}

greet("Alice"); // OK
greet(42);      // Error: Argument of type 'number' is not assignable to parameter of type 'string'.

Each parameter gets its own annotation:

function add(a: number, b: number): number {
  return a + b;
}

add(5, 10);    // OK — returns 15
add(5, "10");  // Error: Argument of type 'string' is not assignable to parameter of type 'number'.

Multiple parameters with different types

function createUser(name: string, age: number, isAdmin: boolean): void {
  console.log(name, age, isAdmin);
}

createUser("Alice", 30, true);  // OK
createUser(30, "Alice", true);  // Error: wrong order of types

How to Annotate Function Return Types

You write the return type after the closing parenthesis of the parameters, before the opening curly brace.

function getWelcomeMessage(name: string): string {
  return "Welcome, " + name;
}

The : string after (name: string) tells TypeScript this function must return a string.

If your function returns the wrong type, TypeScript catches it:

function getAge(): number {
  return "thirty";
  // Error: Type 'string' is not assignable to type 'number'.
}

The `void` return type

Use void when a function does not return anything:

function logMessage(message: string): void {
  console.log(message);
  // No return statement needed
}

void tells TypeScript and other developers: "This function does something but gives nothing back."

Common return type annotations

Return Type	When to Use
`string`	Function returns text
`number`	Function returns a numeric value
`boolean`	Function returns true or false
`void`	Function performs an action but returns nothing
`string[]`	Function returns an array of strings
`number[]`	Function returns an array of numbers

How to Annotate Arrays

To annotate an array, write the type followed by []:

let names: string[] = ["Alice", "Bob", "Charlie"];
let scores: number[] = [95, 87, 72];
let flags: boolean[] = [true, false, true];

TypeScript checks both the array itself and every item inside it:

let names: string[] = ["Alice", "Bob"];
names.push(42);
// Error: Argument of type 'number' is not assignable to parameter of type 'string'.

names.push("David"); // OK

The alternative `Array<type>` syntax

TypeScript also supports a second syntax for arrays using angle brackets:

let names: Array<string> = ["Alice", "Bob"];
let scores: Array<number> = [95, 87];

Both styles do exactly the same thing. Most developers use type[] because it is shorter and easier to read.

How to Annotate Objects

To annotate an object, you write the shape of the object inside curly braces:

let user: { name: string; age: number; isAdmin: boolean };

user = { name: "Alice", age: 30, isAdmin: true };  // OK
user = { name: "Alice", age: 30 };                 // Error: missing 'isAdmin'

TypeScript checks that the object has all the required properties with the right types.

Inline object annotation

You can write the annotation inline when you declare the variable:

let product: { id: number; title: string; price: number } = {
  id: 1,
  title: "TypeScript Book",
  price: 29.99
};

Optional properties in objects

Add a ? after the property name to make it optional:

let profile: { username: string; bio?: string } = {
  username: "alice_dev"
  // bio is optional, so we can skip it
};

Tip: For reusable object shapes, use a type alias or interface instead of writing the annotation inline every time. We cover those in later posts.

How to Annotate Union Types

Sometimes a variable can hold more than one type. Use a union type with the | symbol:

let id: string | number;

id = 101;       // OK
id = "abc_101"; // OK
id = true;      // Error: Type 'boolean' is not assignable to type 'string | number'.

You can use union types on function parameters too:

function printId(id: string | number): void {
  console.log("ID:", id);
}

printId(1);       // OK
printId("abc");   // OK

Note: We cover union types in detail in a later post. This is just a quick look at the annotation syntax.

How to Annotate with `null` and `undefined`

With strict: true, you need to be explicit when a value can be null or undefined.

let selectedItem: string | null = null;   // Can be a string or null
let cachedValue: number | undefined;      // Can be a number or undefined

Without the | null or | undefined, TypeScript will not let you assign those values:

let name: string = null;
// Error: Type 'null' is not assignable to type 'string'.

let name: string | null = null; // OK

What Happens to Annotations After Compilation?

Type annotations do not exist in JavaScript. When TypeScript compiles your code, it removes every annotation.

TypeScript (before compile):

let username: string = "Alice";
let score: number = 100;

function add(a: number, b: number): number {
  return a + b;
}

JavaScript (after compile):

let username = "Alice";
let score = 100;

function add(a, b) {
  return a + b;
}

All the : string, : number, and : boolean parts are stripped out. The output is clean JavaScript with no trace of the types.

This means type annotations have zero runtime cost. They only help you during development.

Annotation vs Inference: When to Write It Yourself

TypeScript can infer many types without annotations. So when should you write them yourself?

Write the annotation when:

You declare a variable without assigning a value right away
The return type of a function is not obvious
TypeScript infers a type that is too broad for your needs
You want to make the code easier to read for your team

Skip the annotation when:

The type is obvious from the assigned value
TypeScript can figure it out from context

// Skip annotation: value makes the type obvious
let name = "Alice";     // TypeScript infers: string
let count = 0;          // TypeScript infers: number
let active = true;      // TypeScript infers: boolean

// Write annotation: no value assigned yet
let username: string;
let retries: number;

// Write annotation: return type is not obvious from function name
function fetchData(): Promise<string> {
  return fetch("/api").then(res => res.text());
}

// Write annotation: function parameter always needs one
function double(n: number): number {
  return n * 2;
}

Full Example Putting It All Together

Here is a small program that uses type annotations throughout:

// Variable annotations
let appName: string = "TaskManager";
let version: number = 1;
let isProduction: boolean = false;

// Array annotation
let taskTitles: string[] = ["Write blog", "Review PR", "Fix bug"];

// Object annotation
let currentUser: { id: number; name: string; email: string } = {
  id: 1,
  name: "Alice",
  email: "alice@example.com"
};

// Function with parameter and return type annotations
function getTaskCount(tasks: string[]): number {
  return tasks.length;
}

// Function with void return type
function logStatus(status: string): void {
  console.log("App status:", status);
}

// Union type annotation
let searchInput: string | number = "";

// Optional value with null
let activeTask: string | null = null;

// Using the annotated values
const count: number = getTaskCount(taskTitles);
logStatus("running");
console.log(`${appName} v${version} — ${count} tasks loaded`);

Common Annotation Mistakes

Mistake 1: Using uppercase type names

let name: String = "Alice"; // Wrong — String is an object, not a primitive
let name: string = "Alice"; // Correct

Mistake 2: Forgetting the return type on public functions

// Unclear what this returns
function getUser(id: number) {
  return { id, name: "Alice" };
}

// Clearer with a return type
function getUser(id: number): { id: number; name: string } {
  return { id, name: "Alice" };
}

Mistake 3: Annotating when TypeScript can already infer the type

// Redundant annotation
let score: number = 100;

// Cleaner: TypeScript infers number from the value
let score = 100;

Mistake 4: Missing annotation on function parameters

// Bad: TypeScript has to guess what 'x' is
function square(x) {
  return x * x;
}

// Good: annotation makes the intent clear
function square(x: number): number {
  return x * x;
}

FAQ

Q: Do I have to annotate every variable?
No. TypeScript can infer many types on its own. Annotate when TypeScript cannot figure out the type, or when you want to make your intent clear to other developers.

Q: Do type annotations affect runtime performance?
No. TypeScript removes all annotations during compilation. The output is plain JavaScript with no types. Annotations have zero impact on how fast your code runs.

Q: What is the difference between a type annotation and a type assertion?
A type annotation tells TypeScript what type something should be. A type assertion (as SomeType) forces TypeScript to treat a value as a specific type, even if it disagrees. Annotations are the safe, standard way. Assertions should be used with care.

Q: Can I use type annotations in JavaScript files?
No. Type annotations only work in .ts files. If you need type hints in .js files, you can use JSDoc comments, but that is a different approach.

Q: Should I annotate the return type of every function?
It is good practice for public functions and exported utilities. For small internal helper functions where the return type is obvious, you can let TypeScript infer it.

Q: What happens if I annotate the wrong type?
TypeScript shows a compile error. For example, if you annotate a variable as number but assign a string, you will see an error immediately. The code will not compile until the mismatch is fixed.

What You Learned

Type annotations use the : type syntax after a variable, parameter, or function name
You can annotate variables, constants, function parameters, return types, arrays, and objects
Annotations are removed during compilation and have no runtime cost
Use void for functions that do not return a value
Use type[] to annotate arrays
Use { key: type } to annotate objects inline
Use | to annotate union types when a value can be more than one type
Write annotations when TypeScript cannot infer the type or when you want to be explicit

Sources: TypeScript Handbook — Type Annotations | TypeScript Tutorial — Type Annotations

How to Use Primitive Types in TypeScript: string, number, and boolean

Krunal Kanojiya — Thu, 11 Jun 2026 03:29:51 +0000

TLDR

TypeScript has 7 primitive types: string, number, boolean, null, undefined, bigint, and symbol. You use them to tell TypeScript what kind of value a variable holds. You write them in lowercase. TypeScript can often figure out the type for you. But knowing how each one works is key to writing safe and clear code.

What Are Primitive Types?

Primitive types are the simplest building blocks in TypeScript. Every piece of data in your program starts with one.

They hold a single value. They are not objects. You cannot add methods or properties to them directly.

TypeScript has 7 primitive types in total:

Type	What It Holds
`string`	Text like names, messages, or IDs
`number`	Any number: integers, decimals, negatives
`boolean`	Only `true` or `false`
`null`	An intentional empty value
`undefined`	A value that was never assigned
`bigint`	Very large whole numbers
`symbol`	A unique identifier value

This article covers all 7. You will use string, number, and boolean the most in everyday TypeScript code.

How to Use the `string` Type

A string holds text. Use it for names, messages, emails, URLs, and any other text data.

Basic string annotation

let firstName: string = "Alice";
let greeting: string = "Hello, world!";
let empty: string = "";

Three ways to write strings

TypeScript supports the same three string styles as JavaScript:

let single: string = 'Single quotes work fine';
let double: string = "Double quotes work too";
let template: string = `Template literals with ${firstName}`;

Template literals (backticks) let you insert values inside a string with ${}. TypeScript checks the types of those inserted values too.

let age: number = 30;
let message: string = `I am ${age} years old`;
// TypeScript checks that 'age' is compatible here

What TypeScript catches with strings

let name: string = "Alice";
name = 42;
// Error: Type 'number' is not assignable to type 'string'.

name = true;
// Error: Type 'boolean' is not assignable to type 'string'.

Once a variable is typed as string, TypeScript blocks you from putting a number or boolean in it.

Common string operations TypeScript knows about

let word: string = "typescript";

word.toUpperCase();   // string
word.length;          // number
word.includes("type"); // boolean
word.split("");       // string[]

TypeScript knows the return type of every built-in string method. This means you get autocomplete and error checking for free.

How to Use the `number` Type

In TypeScript, number covers all numeric values: whole numbers, decimals, and negative numbers. There is no separate int or float type.

All TypeScript numbers are 64-bit floating-point values under the hood.

Basic number annotation

let age: number = 30;
let price: number = 19.99;
let temperature: number = -5;
let zero: number = 0;

Special number values

let infinity: number = Infinity;
let negInfinity: number = -Infinity;
let notANumber: number = NaN;

All three of these are valid number values in TypeScript.

Number formats TypeScript supports

let decimal: number = 255;        // Regular decimal
let hex: number = 0xFF;           // Hexadecimal (255)
let binary: number = 0b11111111;  // Binary (255)
let octal: number = 0o377;        // Octal (255)

All four lines hold the same value: 255. TypeScript accepts all these formats as number.

What TypeScript catches with numbers

let score: number = 100;
score = "one hundred";
// Error: Type 'string' is not assignable to type 'number'.

A common mistake: numbers as strings

let userInput: string = "42"; // This is a string, not a number

let doubled: number = userInput * 2;
// Error: The left-hand side of an arithmetic operation must be
// of type 'any', 'number', 'bigint' or an enum type.

TypeScript stops you from doing math with strings. You need to convert first:

let userInput: string = "42";
let doubled: number = Number(userInput) * 2; // Safe conversion

How to Use the `boolean` Type

A boolean holds one of only two values: true or false. Use it for flags, toggles, conditions, and yes/no states.

Basic boolean annotation

let isLoggedIn: boolean = true;
let hasPermission: boolean = false;
let isLoading: boolean = false;

Booleans from comparisons

Most of the time you do not write true or false by hand. You get booleans from comparisons:

let age: number = 20;
let isAdult: boolean = age >= 18;       // true
let isTeenager: boolean = age < 18;     // false
let isExactly20: boolean = age === 20;  // true

Booleans in conditions

let isLoggedIn: boolean = true;

if (isLoggedIn) {
  console.log("Welcome back!");
} else {
  console.log("Please log in.");
}

What TypeScript catches with booleans

let isActive: boolean = true;
isActive = 1;
// Error: Type 'number' is not assignable to type 'boolean'.

isActive = "yes";
// Error: Type 'string' is not assignable to type 'boolean'.

In JavaScript, 1 and "yes" are both truthy. But TypeScript does not let you assign them to a boolean variable. You must use true or false.

How to Use the `null` Type

null means you are intentionally saying a value is empty or missing. It is a deliberate choice.

let selectedUser: string | null = null;
// No user is selected yet

`null` on its own

You can type a variable as only null. But this is rarely useful on its own.

let nothing: null = null;
nothing = "hello";
// Error: Type 'string' is not assignable to type 'null'.

`null` combined with other types

The real power of null is combining it with other types using a union (|):

let username: string | null = null;

// Later, when the user logs in:
username = "Alice"; // Also valid

Working safely with `null` values

With strict: true, TypeScript forces you to check for null before using a value:

let username: string | null = null;

console.log(username.toUpperCase());
// Error: 'username' is possibly 'null'.

// Fix: Check first
if (username !== null) {
  console.log(username.toUpperCase()); // Safe
}

How to Use the `undefined` Type

undefined means a value was never assigned. TypeScript uses this automatically for uninitialized variables and missing function return values.

let city: string | undefined = undefined;

function findUser(id: number): string | undefined {
  if (id === 1) {
    return "Alice";
  }
  return undefined; // No user found
}

The difference between `null` and `undefined`

This trips up many developers. Here is the key difference:

	`null`	`undefined`
Meaning	"I know there is no value here"	"This has not been set yet"
Set by	You, on purpose	TypeScript or JS automatically
Common use	Function returns no result	Optional properties, unset variables

let a: null = null;          // You chose to leave this empty
let b: undefined = undefined; // This was never set

console.log(typeof a); // "object" (a JavaScript quirk)
console.log(typeof b); // "undefined"

Note: typeof null returns "object" in JavaScript. This is a long-standing bug in the language. TypeScript is aware of this and handles it correctly in type checks.

How to Use the `bigint` Type

bigint is for working with very large whole numbers. The regular number type can safely handle integers up to 2^53 - 1 (which is 9,007,199,254,740,991). Anything bigger needs bigint.

let bigNumber: bigint = 9007199254740992n; // Add 'n' at the end
let anotherBig: bigint = BigInt(9007199254740992);

When to use `bigint`

Working with large database IDs
Financial calculations that need exact integer precision
Cryptography
Scientific computing with very large numbers

What you cannot do with `bigint`

You cannot mix bigint and number in operations:

let big: bigint = 100n;
let regular: number = 50;

let result = big + regular;
// Error: Operator '+' cannot be applied to types 'bigint' and 'number'.

You must convert one to match the other:

let big: bigint = 100n;
let regular: number = 50;

let result = big + BigInt(regular); // Convert number to bigint

Important: bigint only works when your tsconfig.json has "target": "ES2020" or higher.

How to Use the `symbol` Type

symbol creates a completely unique value. No two symbols are ever equal, even if they have the same description.

let id1: symbol = Symbol("id");
let id2: symbol = Symbol("id");

console.log(id1 === id2); // false — they are always unique

When to use `symbol`

Symbols are mainly used as unique keys for object properties. They prevent name clashes when two pieces of code use the same property name.

const USER_ID = Symbol("userId");

const user = {
  [USER_ID]: 123,
  name: "Alice"
};

console.log(user[USER_ID]); // 123

In everyday application code, you will rarely use symbol. It is more common in library code and advanced patterns.

Type Annotations vs Type Inference

You do not always have to write the type yourself. TypeScript can figure it out from the value you assign. This is called type inference.

let name = "Alice";   // TypeScript infers: string
let age = 30;         // TypeScript infers: number
let active = true;    // TypeScript infers: boolean

TypeScript reads the value on the right side and assigns the type automatically.

When should you write the type yourself?

// You SHOULD annotate when declaring without a value
let username: string;
username = "Alice";

// You SHOULD annotate when the type is not obvious
let score: number = calculateScore(); // Makes the return type clear

// You CAN skip annotation when the value is obvious
let count = 0; // No need to write ': number'

A good rule: if the type is obvious from the value, let TypeScript infer it. If the type is not clear, write it yourself.

All 7 Primitive Types at a Glance

// string
let name: string = "Alice";

// number
let age: number = 30;

// boolean
let isActive: boolean = true;

// null
let selected: null = null;

// undefined
let result: undefined = undefined;

// bigint (requires target ES2020+)
let bigId: bigint = 9999999999999999999n;

// symbol
let uniqueKey: symbol = Symbol("key");

Quick Comparison of All Primitive Types

Type	Example Value	Common Use Case
`string`	`"hello"`	Names, messages, URLs
`number`	`42`, `3.14`, `-1`	Scores, prices, ages
`boolean`	`true`, `false`	Flags, toggles, conditions
`null`	`null`	Intentional empty value
`undefined`	`undefined`	Unset variables, optional returns
`bigint`	`9999n`	Very large integers
`symbol`	`Symbol("id")`	Unique object property keys

Common Mistakes with Primitive Types

Mixing types without a union:

let value: string = "hello";
value = 42; // Error: You must use string | number if both are valid

Comparing loosely instead of strictly:

let count: number = 0;

if (count == false) { } // Loose comparison, avoid this
if (count === 0) { }    // Strict comparison, TypeScript-friendly

Confusing null and undefined:

// These are different
let a: null = null;
let b: undefined = undefined;

a === b;  // false
a == b;   // true (loose equality, but TypeScript will warn you)

Writing type names with capital letters:

// Wrong — these are JavaScript wrapper objects, not primitive types
let name: String = "Alice"; // Avoid
let age: Number = 30;       // Avoid
let flag: Boolean = true;   // Avoid

// Correct — always use lowercase
let name: string = "Alice";
let age: number = 30;
let flag: boolean = true;

Always use lowercase. string is the primitive type. String (capital S) is a JavaScript object. They behave differently. Always use the lowercase versions in TypeScript.

FAQ

Q: Does TypeScript have a separate int type for whole numbers?
No. TypeScript uses number for all numeric values including integers and decimals. If you need very large integers, use bigint.

Q: Can a variable hold both a string and a number?
Yes. Use a union type: let value: string | number. We cover union types in detail in a later post.

Q: Should I always annotate my variables with types?
Not always. If TypeScript can infer the type from the value, you do not need to write it. For example, let name = "Alice" is fine without : string. Write annotations when the type is not obvious.

Q: What is the difference between null and undefined in TypeScript?
null means the value is intentionally empty. undefined means the value was never set. Use null when you want to say "there is no value here on purpose." Use undefined for optional or uninitialized values.

Q: Why should I use lowercase string instead of String?
string (lowercase) is the primitive type. String (uppercase) is a JavaScript wrapper object. They are different. Using String can cause unexpected behavior. Always use the lowercase versions.

Q: Does TypeScript have a float type?
No. Both integers and floating-point numbers use the number type. Under the hood, all TypeScript numbers are 64-bit floating-point values.

What You Learned

TypeScript has 7 primitive types: string, number, boolean, null, undefined, bigint, and symbol
string holds text, number holds all numeric values, boolean holds true or false
null is an intentional empty value; undefined means a value was never assigned
bigint handles integers larger than 2^53 - 1 and requires target: ES2020 or higher
symbol creates unique values used as object property keys
TypeScript can infer types from values, so you do not always need to write them
Always use lowercase type names: string, number, boolean, not String, Number, Boolean

Sources: TypeScript Handbook — Basic Types | TypeScript TSConfig Reference

How to Enable Strict Mode and Why You Should Always Use It

Krunal Kanojiya — Wed, 10 Jun 2026 17:33:11 +0000

TLDR

Strict mode in TypeScript turns on 8 safety checks at once with one line: "strict": true in your tsconfig.json. It catches null errors, missing types, uninitialized class properties, and more before your code ever runs. Always enable it on new projects. On older projects, turn on the 8 flags one at a time and fix errors as you go.

What is Strict Mode in TypeScript?

By default, TypeScript is pretty relaxed. It lets you skip types in some places. It does not check for null on every value. It allows some patterns that can crash at runtime.

Strict mode fixes all of that. It is a single switch that turns on a group of type-checking rules all at once.

Think of it like turning on every warning light in a car instead of just the engine light. You see more problems, but that means you fix them before they cause a crash.

How to Enable Strict Mode

Enabling strict mode takes one line in your tsconfig.json.

{
  "compilerOptions": {
    "strict": true
  }
}

That is it. This one setting turns on 8 different checks at the same time.

You can also turn it on temporarily from the command line:

tsc --strict

What Does `strict: true` Actually Turn On?

When you set "strict": true, TypeScript enables these 8 flags automatically:

Flag	What It Checks
`strictNullChecks`	Stops you from using `null` or `undefined` where a real value is expected
`noImplicitAny`	Forces you to add types when TypeScript cannot figure them out
`strictFunctionTypes`	Checks that function parameters match the expected types correctly
`strictBindCallApply`	Makes `.bind()`, `.call()`, and `.apply()` type-safe
`strictPropertyInitialization`	Makes sure class properties are set in the constructor
`noImplicitThis`	Stops you from using `this` when its type is unclear
`useUnknownInCatchVariables`	Makes the `error` variable in `catch` blocks `unknown` instead of `any`
`alwaysStrict`	Adds `"use strict"` to every compiled JavaScript file

You do not need to set any of these one by one. "strict": true handles all of them.

Note: TypeScript may add new flags to the strict group in future versions. When you upgrade TypeScript, those new flags turn on automatically if you have "strict": true. This is a good thing. It means your code gets safer with every upgrade.

Why Each Flag Matters (With Code Examples)

1. `strictNullChecks` — Stop Null Crashes

This is the most important flag. Without it, TypeScript lets you use null and undefined anywhere. This causes runtime crashes.

Without strict:

function getLength(text: string): number {
  return text.length; // No error here
}

getLength(null); // Compiles fine. Crashes at runtime.

With strict:

function getLength(text: string): number {
  return text.length;
}

getLength(null);
// Error: Argument of type 'null' is not assignable
// to parameter of type 'string'.

Now TypeScript forces you to handle the null case before using the value:

function getLength(text: string | null): number {
  if (text === null) {
    return 0;
  }
  return text.length; // TypeScript knows text is a string here
}

2. `noImplicitAny` — No Hidden `any` Types

Without this flag, TypeScript quietly gives some values the type any when it cannot figure out the type. any turns off type checking for that value. It defeats the whole point of using TypeScript.

Without strict:

function processItems(items) { // items is silently 'any'
  items.forEach(item => {
    console.log(item.name); // No type checking at all
  });
}

With strict:

function processItems(items) {
// Error: Parameter 'items' implicitly has an 'any' type.
}

Now you must add a type:

function processItems(items: string[]): void {
  items.forEach(item => {
    console.log(item); // TypeScript checks this correctly
  });
}

3. `strictPropertyInitialization` — Class Properties Must Be Set

Without this flag, you can declare a class property and never set it. Then it is undefined at runtime and causes bugs.

Without strict:

class User {
  name: string; // Never set in constructor

  greet() {
    console.log(this.name.toUpperCase()); // Crashes at runtime
  }
}

With strict:

class User {
  name: string;
  // Error: Property 'name' has no initializer and is not
  // definitely assigned in the constructor.
}

Now you must either set it in the constructor or mark it as optional:

// Option 1: Set it in the constructor
class User {
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

// Option 2: Mark it optional with a default
class User {
  name: string = "Guest";
}

// Option 3: Mark it as possibly undefined
class User {
  name?: string;
}

4. `useUnknownInCatchVariables` — Safe Error Handling

In older TypeScript, the error variable inside a catch block had the type any. That meant you could call any method on it without checking. This could crash.

Without strict:

try {
  doSomething();
} catch (error) {
  console.log(error.message); // error is 'any', no check done
}

With strict:

try {
  doSomething();
} catch (error) {
  console.log(error.message);
  // Error: 'error' is of type 'unknown'.
}

Now you must check what kind of error it is before using it:

try {
  doSomething();
} catch (error) {
  if (error instanceof Error) {
    console.log(error.message); // Safe to use
  } else {
    console.log("Unknown error occurred");
  }
}

5. `strictBindCallApply` — Type-Safe Function Methods

This flag makes .call(), .bind(), and .apply() check that you pass the right argument types.

Without strict:

function greet(name: string): string {
  return `Hello, ${name}`;
}

greet.call(undefined, 42); // Wrong type, but no error

With strict:

function greet(name: string): string {
  return `Hello, ${name}`;
}

greet.call(undefined, 42);
// Error: Argument of type 'number' is not assignable
// to parameter of type 'string'.

6. `noImplicitThis` — Clear `this` Typing

Without this flag, using this inside a regular function is allowed even when TypeScript does not know what this points to.

Without strict:

function printName() {
  console.log(this.name); // 'this' is implicitly 'any'
}

With strict:

function printName() {
  console.log(this.name);
  // Error: 'this' implicitly has type 'any' because it does
  // not have a type annotation.
}

Fix it by adding an explicit this type:

function printName(this: { name: string }) {
  console.log(this.name); // TypeScript knows the shape of 'this'
}

Two Extra Flags Worth Adding

These two flags are NOT included in strict: true. But they are worth turning on for even safer code.

`noUncheckedIndexedAccess`

When you access an array item by index, TypeScript normally assumes the item exists. This flag makes it return T | undefined instead.

const names: string[] = ["Alice", "Bob"];

// Without noUncheckedIndexedAccess
const first: string = names[0]; // TypeScript thinks this is always a string

// With noUncheckedIndexedAccess
const first: string | undefined = names[0]; // Safer, might be undefined
if (first !== undefined) {
  console.log(first.toUpperCase()); // Now safe to use
}

`noImplicitOverride`

This flag makes you add the override keyword when you override a method in a subclass. It prevents silent bugs when the parent class changes.

class Animal {
  makeSound() {
    console.log("...");
  }
}

// Without noImplicitOverride: no error even if parent renames the method
class Dog extends Animal {
  makeSound() { // Silently breaks if parent renames makeSound()
    console.log("Woof");
  }
}

// With noImplicitOverride: you must write override
class Dog extends Animal {
  override makeSound() { // Clear intent, compiler verifies parent has this
    console.log("Woof");
  }
}

Add them to your tsconfig.json alongside strict:

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true
  }
}

The Full Recommended Strict Config

Here is the complete set of strict options we recommend for all new TypeScript projects:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true
  }
}

Here is what the extra flags do:

Flag	What It Does
`noUnusedLocals`	Errors on variables that are declared but never used
`noUnusedParameters`	Errors on function parameters that are never used
`noImplicitReturns`	Errors when a function does not return a value on all paths

What the Same Code Looks Like Without and With Strict Mode

Here is a real example. This function has two silent bugs without strict mode.

Without strict mode (no errors shown):

function getUserCity(user) {
  return user.address.city;
}

const city = getUserCity(null);
console.log(city.toUpperCase());

This code compiles with no errors. But it will crash at runtime because:

user could be null
user.address could be undefined
city could be undefined

With strict mode (all bugs caught at compile time):

// Error on line 1: Parameter 'user' implicitly has an 'any' type.
function getUserCity(user) {
  return user.address.city;
}

TypeScript stops you right away. You now write a safe version:

type Address = {
  city: string;
};

type User = {
  address: Address | null;
};

function getUserCity(user: User | null): string {
  if (user === null || user.address === null) {
    return "Unknown";
  }
  return user.address.city;
}

const city = getUserCity(null);
console.log(city.toUpperCase()); // Always safe

How to Enable Strict Mode on an Existing Project

If you are adding TypeScript to an older project, turning on strict: true all at once can show hundreds of errors. That is overwhelming.

Do it step by step instead.

Step 1: Keep strict off. Turn on flags one at a time.

{
  "compilerOptions": {
    "strict": false,
    "noImplicitAny": true
  }
}

Step 2: Fix all the errors from that flag. Commit your changes.

Step 3: Add the next flag.

{
  "compilerOptions": {
    "strict": false,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

Step 4: Keep going until all 8 flags are on. Then replace them all with "strict": true.

Here is a good order to follow when migrating:

Step	Flag to Enable	Why This Order
1	`noImplicitAny`	Easiest to fix, forces you to add types
2	`strictNullChecks`	Most impactful, stops null crashes
3	`strictPropertyInitialization`	Fixes class property bugs
4	`strictFunctionTypes`	Catches function type mismatches
5	`strictBindCallApply`	Usually few errors, easy to fix
6	`noImplicitThis`	Quick fixes with `this` annotations
7	`useUnknownInCatchVariables`	Makes catch blocks safer
8	`alwaysStrict`	Adds `"use strict"` to JS output

Does Strict Mode Change the JavaScript Output?

No. Strict mode is a compile-time feature only.

All the checks happen when you run tsc. The compiled JavaScript output is identical whether strict mode is on or off.

The only exception is alwaysStrict. That flag adds "use strict" at the top of every compiled JavaScript file. But that is a JavaScript directive, not a TypeScript type change.

Common Errors You Will See After Enabling Strict Mode

Here are the errors developers hit most often after turning on strict mode.

"Object is possibly null"

const el = document.getElementById("app");
el.innerHTML = "Hello"; 
// Error: 'el' is possibly 'null'.

// Fix:
const el = document.getElementById("app");
if (el !== null) {
  el.innerHTML = "Hello";
}

"Parameter implicitly has an 'any' type"

function double(n) { // Error
  return n * 2;
}

// Fix:
function double(n: number): number {
  return n * 2;
}

"Property has no initializer"

class Cart {
  items: string[]; // Error
}

// Fix:
class Cart {
  items: string[] = [];
}

"Not all code paths return a value"

function grade(score: number) {
  if (score >= 90) {
    return "A";
  }
  // Error: Function lacks ending return statement
}

// Fix:
function grade(score: number): string {
  if (score >= 90) {
    return "A";
  }
  return "B";
}

FAQ

Q: Does strict mode make TypeScript harder to use?
At first, yes. You will see more errors. But each error points to a real bug. Over time, your code becomes more reliable and easier to maintain.

Q: Can I turn off just one strict flag?
Yes. You can override any individual flag even with strict: true. For example, if you want everything except alwaysStrict, set it to false after enabling strict:

{
  "compilerOptions": {
    "strict": true,
    "alwaysStrict": false
  }
}

Q: Should I use strict mode on a team project?
Yes. Always. Agree on it at the start of the project so the whole team works with the same rules.

Q: Is strict: true the default?
No. TypeScript defaults to strict: false. You have to opt in. This is why you should always set it manually.

Q: Does strict mode slow down compilation?
A tiny bit. More checks take more time. But the difference is not noticeable on most projects.

Q: What is the difference between strict and strictNullChecks?
strictNullChecks is one of the 8 checks inside strict: true. Setting strict: true includes strictNullChecks plus 7 other checks. Always use strict: true instead of setting individual flags one by one on new projects.

What You Learned

"strict": true in tsconfig.json turns on 8 safety checks at once
strictNullChecks stops null crashes before they happen at runtime
noImplicitAny forces you to add proper types everywhere
strictPropertyInitialization catches unset class properties
useUnknownInCatchVariables makes error handling safer
Add noUncheckedIndexedAccess and noImplicitOverride for even more safety
On new projects, always start with strict: true
On existing projects, enable each flag one at a time and fix errors before adding the next

Sources: TypeScript TSConfig Reference | TypeScript Official Docs — Strict Mode

How to Use the TypeScript Compiler (tsc) to Compile Your Code

Krunal Kanojiya — Wed, 10 Jun 2026 03:41:20 +0000

TLDR

tsc is the TypeScript compiler. It turns your .ts files into .js files that Node.js and browsers can run. Install it with npm install -g typescript. Run tsc to compile your whole project. Run tsc --watch to auto-compile on every file save. Run tsc --noEmit to check for errors without creating any files.

What is the TypeScript Compiler?

The TypeScript compiler is a tool called tsc. It reads your TypeScript files and turns them into JavaScript files.

Your browser and Node.js cannot run TypeScript directly. They only understand JavaScript. So tsc acts as the bridge between what you write and what actually runs.

Think of tsc like a spell checker for your code. It finds problems before your code ever runs. Then it produces clean JavaScript output for you.

How to Install the TypeScript Compiler

You install tsc using npm. There are two ways to do this.

Option 1: Global Install (runs anywhere on your computer)

npm install -g typescript

After install, check it works:

tsc --version

You will see something like Version 6.0.3.

Option 2: Local Install (recommended for teams)

npm install --save-dev typescript

Then run it using npx:

npx tsc --version

Which one should you use? Use a local install for project work. This makes sure everyone on your team uses the same TypeScript version. Use a global install only for quick personal experiments.

How to Compile a Single TypeScript File

The simplest way to use tsc is to pass it a single file.

Create a file called hello.ts:

const message: string = "Hello, TypeScript!";
console.log(message);

Now compile it:

tsc hello.ts

This creates a new file called hello.js in the same folder:

var message = "Hello, TypeScript!";
console.log(message);

Notice that TypeScript removed the : string type annotation. The output is plain JavaScript that Node.js can run.

Run the output file:

node hello.js
# Hello, TypeScript!

Important: When you pass a file directly to tsc, it ignores your tsconfig.json. It uses its own default settings instead. For real projects, always use tsconfig.json.

How to Compile Your Whole Project

For most projects, you will not compile one file at a time. You will compile the whole project using tsconfig.json.

Just run tsc with no arguments:

tsc

TypeScript will look for a tsconfig.json in your current folder. It reads the settings and compiles all included .ts files.

If your tsconfig.json has this setup:

{
  "compilerOptions": {
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"]
}

Running tsc will take all files from src/ and put compiled .js files into dist/.

Before tsc:             After tsc:
src/                    src/
  index.ts                index.ts
  utils.ts                utils.ts
                        dist/
                          index.js
                          utils.js

How to Use Watch Mode (Auto-Compile on Save)

Running tsc by hand every time you change a file is slow. Watch mode fixes this.

tsc --watch

Or use the short form:

tsc -w

Now TypeScript watches all your files. Every time you save a .ts file, it recompiles automatically. You will see output like this:

[12:10:01 PM] Starting compilation in watch mode...
[12:10:02 PM] Found 0 errors. Watching for file changes.

[12:10:45 PM] File change detected. Starting incremental compilation...
[12:10:45 PM] Found 0 errors. Watching for file changes.

To stop watch mode, press CTRL + C in your terminal.

Tip: Keep watch mode running in a terminal tab while you code. You will see errors right away instead of finding them later.

How to Type-Check Without Creating Files

Sometimes you just want to check for type errors. You do not want to produce any JavaScript output.

Use the --noEmit flag:

tsc --noEmit

This runs all the type checks and prints any errors. But it does not create any .js files.

This is very useful in two places:

In your CI/CD pipeline to make sure code passes type checks before deploying
Before a commit to catch bugs without building the whole project

# Check types only, no output files
tsc --noEmit

# Check types in watch mode (good during development)
tsc --noEmit --watch

How to Use a Specific Config File

By default, tsc looks for tsconfig.json in your current folder. You can tell it to use a different config file with --project.

tsc --project tsconfig.prod.json

Or use the short form:

tsc -p tsconfig.prod.json

This is useful when you have different builds. For example:

Config File	Used For
`tsconfig.json`	Default development settings
`tsconfig.prod.json`	Production build with stricter settings
`tsconfig.test.json`	Test environment settings

Most Useful tsc CLI Flags

Here is a list of the flags you will use the most.

Flag	Short Form	What It Does
`--watch`	`-w`	Recompile automatically on file changes
`--noEmit`		Check types only, no JS output
`--project`	`-p`	Use a specific config file
`--init`		Create a new `tsconfig.json`
`--version`	`-v`	Show the TypeScript version
`--help`	`-h`	Show all available options
`--listFiles`		Print all files being compiled
`--showConfig`		Print the full merged config
`--incremental`		Speed up builds by caching
`--strict`		Enable strict mode for this run
`--target`		Set the JS output version for this run
`--outDir`		Set the output folder for this run

How to Pass Flags Without tsconfig.json

You can pass compilerOptions directly from the command line. This is useful for quick tests.

# Compile a file targeting ES2022 output
tsc index.ts --target ES2022

# Compile two files into one output file
tsc app.ts utils.ts --target ESNext --outFile bundle.js

# Compile with strict mode on
tsc index.ts --strict

Remember: Flags passed on the command line override what is in your tsconfig.json. Use this only for testing and one-off tasks.

How to Debug Compilation Problems

When something goes wrong with compilation, these two flags help you figure out what is happening.

`--listFiles`

This shows you every file TypeScript is including in the compilation.

tsc --listFiles

Output example:

/usr/local/lib/node_modules/typescript/lib/lib.es2022.d.ts
/home/user/project/src/index.ts
/home/user/project/src/utils.ts

Use this when TypeScript is compiling files you did not expect.

`--showConfig`

This prints the full merged config that TypeScript is actually using.

tsc --showConfig

Output example:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "commonjs",
    "strict": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "files": [
    "./src/index.ts",
    "./src/utils.ts"
  ]
}

Use this when you are not sure what settings are active. This is especially helpful when you use extends to inherit from another config file.

Understanding tsc Exit Codes

Exit codes tell you if the compilation succeeded or failed. This matters a lot in CI/CD pipelines.

Exit Code	Meaning
`0`	Compilation succeeded with no errors
`1`	Compilation failed with errors
`2`	Invalid compiler arguments were passed

You can check the exit code in your shell like this:

tsc --noEmit
echo $?   # Prints 0 if no errors, 1 if there are errors

In a GitHub Actions workflow, you can use this pattern:

- name: Type check
  run: npx tsc --noEmit

If there are type errors, the pipeline stops and fails. This prevents broken code from being deployed.

How to Speed Up Compilation with Incremental Mode

For large projects, tsc can take a long time to compile. Incremental mode speeds things up by remembering what it compiled last time.

Turn it on in your tsconfig.json:

{
  "compilerOptions": {
    "incremental": true
  }
}

Or use the flag directly:

tsc --incremental

The first run will take the same amount of time. But every run after that will be much faster because TypeScript only recompiles files that changed.

TypeScript stores a cache in a file called .tsbuildinfo. Do not delete this file if you want faster builds.

my-project/
├── src/
├── dist/
├── tsconfig.json
└── tsconfig.tsbuildinfo    <-- build cache, keep this

Tip: Add .tsbuildinfo to your .gitignore file. There is no need to commit it.

How to Use tsc in Your package.json Scripts

Most developers add tsc commands to their package.json so the team does not have to remember flags.

{
  "scripts": {
    "build": "tsc",
    "build:watch": "tsc --watch",
    "type-check": "tsc --noEmit",
    "type-check:watch": "tsc --noEmit --watch"
  }
}

Now your team can run simple commands:

npm run build           # Compile the project
npm run build:watch     # Compile and watch for changes
npm run type-check      # Check types without building

This is a clean workflow that works for every developer on your team.

Common tsc Errors and What They Mean

Here are some errors you will see when starting out.

Error: Cannot find a tsconfig.json file

error TS5083: Cannot read file '/project/tsconfig.json'.

Fix: Make sure you are in the right folder. Run tsc --init if you do not have a tsconfig.json yet.

Error: Argument of type is not assignable

error TS2345: Argument of type 'number' is not assignable to parameter of type 'string'.

Fix: You passed the wrong type to a function. Check your function's expected parameter types.

Error: rootDir is expected to contain all source files

error TS6059: File '/project/tests/app.test.ts' is not under 'rootDir' '/project/src'.

Fix: Your rootDir does not include all your .ts files. Update rootDir or adjust your include list.

Error: Cannot write file because it would overwrite input file

error TS5055: Cannot write file 'index.js' because it would overwrite input file.

Fix: Set an outDir in your tsconfig.json. TypeScript cannot save output files to the same place as source files.

Full Workflow Example

Here is a complete example of a TypeScript project using tsc the right way.

Project structure:

my-app/
├── src/
│   ├── index.ts
│   └── math.ts
├── tsconfig.json
└── package.json

src/math.ts:

export function add(a: number, b: number): number {
  return a + b;
}

src/index.ts:

import { add } from "./math";

const result: number = add(5, 3);
console.log(result);

tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "strict": true,
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src"]
}

package.json scripts:

{
  "scripts": {
    "build": "tsc",
    "dev": "tsc --watch",
    "type-check": "tsc --noEmit"
  }
}

Now run:

npm run build

You will get:

dist/
  index.js
  math.js

Run the output:

node dist/index.js
# 8

That is a clean, working TypeScript workflow using tsc.

FAQ

Q: Do I need to run tsc every time I save a file?
No. Use tsc --watch and it will recompile automatically every time you save.

Q: Can I run TypeScript files without compiling?
Yes. Tools like ts-node and tsx can run TypeScript directly without a separate compile step. But for production use, you should always compile with tsc first.

Q: What is the difference between tsc and npx tsc?
If you installed TypeScript globally, use tsc. If you installed it locally in your project, use npx tsc. npx picks up the local version from your node_modules.

Q: Does tsc minify my JavaScript output?
No. tsc does not minify code. It only compiles TypeScript to JavaScript. For minification, use a bundler like Vite, Webpack, or esbuild.

Q: Why does tsc still output files even when there are errors?
By default, tsc emits JavaScript even if there are type errors. To stop this, set "noEmitOnError": true in your tsconfig.json.

Q: How do I compile only changed files to make builds faster?
Use "incremental": true in your tsconfig.json. TypeScript will cache the last build and only recompile changed files.

What You Learned

tsc is the TypeScript compiler that turns .ts files into .js files
Install with npm install --save-dev typescript and run with npx tsc
Run tsc to compile your whole project using tsconfig.json
Use --watch to auto-compile on every file save
Use --noEmit to type-check without creating files
Use --project to point to a specific config file
Use --showConfig and --listFiles to debug compilation issues
Add tsc commands to your package.json scripts so your whole team can use them

Sources: TypeScript Official tsc CLI Docs | TypeScript TSConfig Reference

How to Configure tsconfig.json for Your TypeScript Project

Krunal Kanojiya — Tue, 09 Jun 2026 02:59:41 +0000

TLDR

tsconfig.json is the config file for every TypeScript project. It tells the TypeScript compiler what to check and how to build your code. Run tsc --init to create one. The key options you need to know are target, module, strict, outDir, and rootDir. Always turn on strict mode. It saves you from many bugs.

What is tsconfig.json?

tsconfig.json is a file that lives at the root of your TypeScript project. It controls how TypeScript compiles your code.

When you run tsc in your terminal, TypeScript looks for this file first. It reads your settings and uses them to type-check and compile your .ts files.

Without this file, the TypeScript compiler uses its default settings. Those defaults are not always the best for your project. That is why you should always create and customize your own tsconfig.json.

How to Create tsconfig.json

You do not have to write this file by hand. TypeScript gives you a command to create one.

Step 1: Make sure TypeScript is installed.

npm install -g typescript

Step 2: Run the init command in your project folder.

tsc --init

This creates a tsconfig.json file with many options inside it. Most of them are commented out.

Your project folder should look like this:

my-project/
├── src/
│   └── index.ts
├── tsconfig.json
└── package.json

The Structure of tsconfig.json

A tsconfig.json file has a few top-level keys. Here is what each one does:

Key	What It Does
`compilerOptions`	Controls how TypeScript compiles your code
`include`	Tells TypeScript which folders or files to compile
`exclude`	Tells TypeScript which folders or files to skip
`files`	Lists specific files to include (rarely used)
`extends`	Lets you inherit settings from another config file

The most important key is compilerOptions. This is where all the action happens.

Here is a basic example of the full structure:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

Core Compiler Options Explained

There are hundreds of compiler options. You do not need to know all of them. Here are the ones you will use in almost every project.

Option	Type	Default	What It Does
`target`	string	`ES3`	Sets the JavaScript version for output
`module`	string	depends	Sets how modules are handled
`strict`	boolean	`false`	Turns on all strict type checks
`outDir`	string	none	Folder where compiled JS files go
`rootDir`	string	none	Root folder of your TypeScript source files
`lib`	array	depends	Built-in type definitions to include
`sourceMap`	boolean	`false`	Creates `.map` files for debugging
`declaration`	boolean	`false`	Creates `.d.ts` type files
`skipLibCheck`	boolean	`false`	Skips type checking of `.d.ts` files
`esModuleInterop`	boolean	`false`	Allows default imports from CommonJS modules
`resolveJsonModule`	boolean	`false`	Lets you import `.json` files

How to Set the `target` Option

The target option tells TypeScript which version of JavaScript to compile your code to.

For example, if you set target to ES5, TypeScript turns your modern arrow functions into old function expressions. If you set it to ES2020, it keeps modern syntax as-is.

Which target should you pick?

Target	Use It When
`ES5`	You need to support very old browsers
`ES6` / `ES2015`	Older Node.js projects
`ES2017`	You want `async/await` in the output
`ES2020`	Good default for most modern projects
`ES2022`	Best for modern Node.js (v16+)
`ESNext`	Always use the latest JS features

{
  "compilerOptions": {
    "target": "ES2022"
  }
}

Tip: ES2022 is a safe and modern choice for most new projects in 2025. It is stable and supported by all modern browsers and Node.js versions.

How to Set the `module` Option

The module option controls how TypeScript handles import and export statements in the compiled output.

This option depends on where your code will run.

`module` Value	Use It When
`CommonJS`	Building for Node.js
`ESNext`	Building for modern browsers or bundlers like Vite
`NodeNext`	Building for Node.js with native ES modules support
`AMD`	Old browser projects (rarely used now)

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS"
  }
}

For most Node.js projects, use CommonJS. For browser projects with a bundler like Vite or Webpack, use ESNext.

How to Enable Strict Mode

strict is the most important option in tsconfig.json. It turns on a group of type-checking rules all at once.

When strict is true, TypeScript becomes much better at catching bugs before your code runs.

Here is what strict: true turns on for you:

Option Enabled	What It Prevents
`strictNullChecks`	Using `null` or `undefined` where a value is expected
`noImplicitAny`	Using variables without a type
`strictFunctionTypes`	Wrong function parameter types
`strictPropertyInitialization`	Class properties that are never set
`useUnknownInCatchVariables`	Unsafe use of `catch` error variables

{
  "compilerOptions": {
    "strict": true
  }
}

Always set strict: true. Starting without it and adding it later is painful. You will have a lot of errors to fix. Start strict from day one.

How to Set `outDir` and `rootDir`

These two options work together. They control where TypeScript reads your source files from and where it puts the compiled JavaScript files.

rootDir points to your TypeScript source folder (usually ./src)
outDir points to the folder where compiled files should go (usually ./dist)

{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  }
}

After running tsc, your project will look like this:

my-project/
├── src/
│   ├── index.ts       <-- TypeScript source
│   └── utils.ts
├── dist/
│   ├── index.js       <-- Compiled JavaScript
│   └── utils.js
├── tsconfig.json
└── package.json

Tip: Add dist to your .gitignore file. You do not need to commit compiled files to Git.

How to Configure `include` and `exclude`

These two options sit outside compilerOptions. They control which files TypeScript looks at.

include tells TypeScript which files or folders to compile:

{
  "include": ["src", "tests"]
}

exclude tells TypeScript which files or folders to ignore:

{
  "exclude": ["node_modules", "dist", "**/*.spec.ts"]
}

By default, TypeScript excludes node_modules automatically. But it is a good habit to list it yourself so nothing surprises you.

How to Set Up Path Aliases with `paths`

Path aliases let you use short import names instead of long relative paths.

Without aliases, your imports look like this:

import { formatDate } from "../../../utils/formatDate";

With path aliases, the same import looks like this:

import { formatDate } from "@utils/formatDate";

Here is how to set that up in tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@utils/*": ["src/utils/*"],
      "@models/*": ["src/models/*"],
      "@services/*": ["src/services/*"]
    }
  }
}

Important: paths in tsconfig.json is only for TypeScript. If you use a bundler (like Webpack or Vite), you need to set up the same aliases in your bundler config too.

How to Add `lib` for Extra Type Definitions

The lib option tells TypeScript which built-in type definitions to include.

If you are building for browsers, you need the DOM types. If you are building for Node.js, you do not.

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM", "DOM.Iterable"]
  }
}

`lib` Value	Includes Types For
`ES2022`	Modern JavaScript APIs
`DOM`	Browser APIs like `document` and `window`
`DOM.Iterable`	Iterating over DOM collections
`ESNext`	The very latest JS features

For Node.js projects, skip DOM and just use ["ES2022"].

How to Enable Source Maps for Debugging

Source maps connect your compiled JavaScript back to your original TypeScript code. This makes debugging much easier in tools like VS Code and browser dev tools.

{
  "compilerOptions": {
    "sourceMap": true
  }
}

This creates a .map file next to each compiled .js file. Debuggers use these files to show you the TypeScript line number when something breaks.

Complete tsconfig.json Templates

Here are two ready-to-use configs you can copy.

For a Node.js Project

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "CommonJS",
    "lib": ["ES2022"],
    "rootDir": "./src",
    "outDir": "./dist",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "resolveJsonModule": true,
    "declaration": false
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

For a Browser App (with a Bundler like Vite)

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "rootDir": "./src",
    "outDir": "./dist",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "sourceMap": true,
    "moduleResolution": "Bundler",
    "resolveJsonModule": true
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

Common Mistakes to Avoid

Here are the most common tsconfig.json mistakes developers make.

Not enabling strict: true -- You will miss many bugs that TypeScript would have caught.
Wrong rootDir path -- If TypeScript cannot find your source files, it will not compile.
Forgetting to exclude node_modules -- TypeScript may try to compile third-party packages and throw errors.
Mismatched target and lib -- If your lib has features that your target does not support, you get errors.
Using paths without baseUrl -- Path aliases do not work unless baseUrl is also set.

Quick Reference: Most Used Options

Option	Recommended Value	Reason
`target`	`ES2022`	Modern and stable
`module`	`CommonJS` (Node) / `ESNext` (browser)	Matches your runtime
`strict`	`true`	Catch more bugs at compile time
`rootDir`	`./src`	Keeps source organized
`outDir`	`./dist`	Keeps compiled files separate
`esModuleInterop`	`true`	Easier imports from npm packages
`skipLibCheck`	`true`	Faster builds
`sourceMap`	`true`	Better debugging

FAQ

Q: Do I need a tsconfig.json file?
Yes. Without it, TypeScript uses defaults that may not match your project. Always create one.

Q: Can I have more than one tsconfig.json?
Yes. Large projects often have multiple config files. You can use extends to share settings between them.

Q: What does skipLibCheck: true do?
It tells TypeScript to skip type checking inside .d.ts files from your node_modules. This speeds up compilation. It is safe to turn on for most projects.

Q: What is the difference between target and lib?
target sets the JavaScript version of your output. lib sets which built-in type definitions TypeScript knows about. They are related but separate.

Q: Should I commit tsconfig.json to Git?
Yes. Always commit tsconfig.json. It is part of your project setup. Do not commit the dist folder.

Q: Why does TypeScript say "rootDir is expected to contain all source files"?
This happens when TypeScript finds a .ts file outside your rootDir. Check if your test files or other config files are placed inside rootDir or adjust your include and rootDir settings.

What You Learned

tsconfig.json is the config file for TypeScript projects
You create it with tsc --init
compilerOptions controls how TypeScript compiles your code
Always use strict: true to catch more bugs
rootDir sets where your source files are and outDir sets where compiled files go
Use include and exclude to control which files TypeScript processes
Path aliases (paths) make imports cleaner

Sources: TypeScript Official Docs | Total TypeScript TSConfig Cheat Sheet

Dual Encoder vs Cross-Encoder: Why Your RAG Pipeline Needs Both

Krunal Kanojiya — Wed, 27 May 2026 16:30:00 +0000

My RAG pipeline looked fine on paper. Fast retrieval. Decent cosine scores. But when I tested it with real queries, the top results were always a little off. Documents that shared vocabulary with the query kept showing up instead of documents that actually answered it. The model was doing its job. The architecture was not.

The fix was not a better model. It was a second model doing a different job.

This post breaks down what that means, why it matters, and how to build the two-stage pipeline in Python.

The Problem With Single-Stage Retrieval

Every search system faces a hard tradeoff between speed and accuracy.

You cannot run a deep computation against every document in a million-item corpus at query time. The latency would be unacceptable. So most pipelines use a fast embedding model to retrieve candidates, stop there, and call it done.

The result is a "close but not quite right" problem. The retrieved documents are topically related but not precisely relevant. The pipeline optimized for speed at the cost of meaning.

Single-stage pipeline (the common mistake):
=============================================
  Query --> [Dual Encoder] --> Top-K results
                               (fast, imprecise)
=============================================

Two-stage pipeline (what actually works):
=============================================
  Query --> [Dual Encoder] --> Top-50 candidates
                --> [Cross-Encoder] --> Reranked Top-5
                                        (fast + precise)
=============================================

The two models are not competing alternatives. They solve different halves of the same problem.

What a Dual Encoder Does

A dual encoder, also called a bi-encoder or two-tower model, uses two separate transformer networks. One encodes the query. The other encodes the document. Both produce a fixed-size vector. Then the system measures cosine similarity between the two vectors.

That single number is the relevance signal.

The reason this is fast is precomputation. You encode every document at index time and store those vectors. At query time, you only encode the query, which takes milliseconds, and run an approximate nearest-neighbor search against precomputed vectors. Corpus size stops mattering for latency.

from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer("all-MiniLM-L6-v2")

# Encoded once at index time and stored
documents = [
    "Python is a high-level programming language.",
    "Transformer models revolutionized NLP benchmarks.",
    "Cosine similarity measures the angle between two vectors.",
    "RAG systems combine retrieval with language model generation.",
]
doc_embeddings = model.encode(documents, convert_to_numpy=True)

# Only this runs at query time
query = "How does vector similarity work in search?"
query_embedding = model.encode(query, convert_to_numpy=True)

scores = np.dot(doc_embeddings, query_embedding) / (
    np.linalg.norm(doc_embeddings, axis=1) * np.linalg.norm(query_embedding)
)

ranked = sorted(zip(scores, documents), reverse=True)
for score, doc in ranked[:3]:
    print(f"{score:.4f} | {doc}")

The tradeoff is that the query and document never actually interact. Each gets compressed into one vector independently. That compression loses nuance. The model has no way to understand whether the document answers the query. It only knows whether they live in the same region of vector space.

What a Cross-Encoder Does

A cross-encoder takes the query and a candidate document as a single concatenated input: [CLS] query [SEP] document [SEP]. One transformer runs on this joint sequence. Every query token attends to every document token across all layers. The output is a single relevance score from 0 to 1.

Because the model reads both at the same time, it catches what a dual encoder misses. It understands negation. It distinguishes between a document that mentions a concept and a document that answers a question about it. It scores based on whether the document actually addresses the query, not whether they share vocabulary.

from sentence_transformers.cross_encoder import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

query = "side effects of stopping medication suddenly"

candidates = [
    "Medication dosage guidelines for common prescriptions.",
    "Abrupt discontinuation of certain medications can cause withdrawal symptoms.",
    "Drug interaction checkers and pharmacy tools.",
    "How to schedule medication reminders on your phone.",
]

pairs = [[query, doc] for doc in candidates]
scores = reranker.predict(pairs)

ranked = sorted(zip(scores, candidates), reverse=True)
for score, doc in ranked:
    print(f"{score:.4f} | {doc}")

The cost is real. Every cross-encoder call requires a full transformer forward pass on the combined input. Nothing can be precomputed. At query time, each candidate costs a separate forward pass. Running this against a million documents is not viable.

This is why you chain them.

The Two-Stage Pipeline

Stage one uses the dual encoder to retrieve the top 50 to 100 candidates. High recall matters here. Any relevant document that misses this cut is permanently gone.

Stage two passes only those candidates to the cross-encoder for reranking. The corpus is now small enough that deep joint attention is computationally viable. The reranker reorders the list. Only the top 5 to 10 results reach the user or the LLM.

from sentence_transformers import SentenceTransformer
from sentence_transformers.cross_encoder import CrossEncoder
import numpy as np

retriever = SentenceTransformer("all-MiniLM-L6-v2")
reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

corpus = [
    "Stopping blood pressure medication without a doctor's guidance can be dangerous.",
    "Common blood pressure drugs include ACE inhibitors and beta blockers.",
    "Medication adherence improves outcomes in chronic disease management.",
    "Withdrawal effects vary depending on the type and duration of medication use.",
    "Pharmacists can review drug interactions and dosage schedules.",
    "Abrupt cessation of antidepressants can cause discontinuation syndrome.",
    "Always consult a physician before changing any medication regimen.",
    "Over-the-counter pain relievers are generally safe for short-term use.",
]

query = "is it dangerous to stop taking my medication without a doctor?"

# Stage 1: Dual encoder retrieval
doc_embeddings = retriever.encode(corpus, convert_to_numpy=True)
query_embedding = retriever.encode(query, convert_to_numpy=True)

cosine_scores = np.dot(doc_embeddings, query_embedding) / (
    np.linalg.norm(doc_embeddings, axis=1) * np.linalg.norm(query_embedding)
)

top_k = 5
top_indices = np.argsort(cosine_scores)[::-1][:top_k]
candidates = [corpus[i] for i in top_indices]

print("Stage 1 - Dual Encoder Retrieval:")
for i, doc in enumerate(candidates):
    print(f"  {i+1}. {doc}")

# Stage 2: Cross-encoder reranking
pairs = [[query, doc] for doc in candidates]
rerank_scores = reranker.predict(pairs)

final_results = sorted(zip(rerank_scores, candidates), reverse=True)

print("\nStage 2 - Cross-Encoder Reranked:")
for score, doc in final_results:
    print(f"  {score:.4f} | {doc}")

Note for RAG builders: The ceiling of this pipeline is always stage one recall. If the dual encoder misses a relevant document entirely, the cross-encoder never sees it. Retrieve generously with a higher top-k, then rerank aggressively.

Side-by-Side Comparison

Property	Dual Encoder	Cross-Encoder
Input format	Query and document encoded separately	Query and document concatenated as one input
Output	Two vectors, cosine compared	One relevance score per pair
Speed	Very fast, supports precomputation	Slow, no precomputation possible
Accuracy	Moderate, misses nuanced relevance	High, full query-document interaction
Scalability	Scales to millions of documents	Practical only on 50 to 200 candidates
Pipeline role	Stage 1 retrieval	Stage 2 reranking
Example models	all-MiniLM-L6-v2, text-embedding-ada-002	ms-marco-MiniLM-L-6-v2, Cohere Rerank, BGE-Reranker
Token interaction	None (independent encoding)	Full cross-attention across all layers

When to Use What

Scenario	Recommended Approach
Corpus under 500 documents	Cross-encoder directly, skip dual encoder
Large corpus, latency is the priority	Dual encoder only
Large corpus, accuracy matters	Dual encoder retrieval plus cross-encoder reranking
High QPS, tight latency budget	Dual encoder plus ColBERT late interaction
Domain-specific content, general models underperform	Fine-tune the cross-encoder on your domain data
Multilingual corpus	BGE-Reranker or mGTE for multilingual reranking

ColBERT: The Middle Ground Worth Knowing

If cross-encoder latency is too high for your QPS budget, ColBERT is worth knowing. It sits between the two architectures. It encodes query and document separately like a dual encoder, preserving the ability to precompute document vectors. But instead of comparing two pooled vectors, it compares individual token embeddings using a MaxSim operation: for each query token, find the most similar document token across the full sequence.

This gives ColBERT much better accuracy than a standard dual encoder while keeping document precomputation intact. According to the original ColBERT paper from Stanford, it uses two orders of magnitude fewer FLOPs per query than a cross-encoder while maintaining strong retrieval quality. The RAGatouille library is the fastest way to plug ColBERT into an existing pipeline.

Approach	Precompute Docs	Token Interaction	Speed	Accuracy
Dual Encoder	Yes	None	Fastest	Lowest
ColBERT	Yes (per token)	MaxSim per token	Fast	High
Cross-Encoder	No	Full cross-attention	Slowest	Highest

FAQs

What is a dual encoder in NLP?
A dual encoder encodes the query and document into separate vectors and computes cosine similarity between them for fast, scalable retrieval.

What is a cross-encoder?
A cross-encoder takes a query and document as a single concatenated input and produces one precise relevance score by attending to both simultaneously.

Why not use a cross-encoder for all retrieval?
Cross-encoders cannot precompute anything, so running one against millions of documents at query time is computationally infeasible.

What is the two-stage retrieval pipeline?
The dual encoder retrieves the top 50 to 100 candidates for speed, then the cross-encoder reranks only those candidates for precision before passing results to the user or LLM.

What is ColBERT?
ColBERT is a late-interaction model that sits between dual and cross-encoders, comparing per-token vectors with MaxSim instead of pooled vectors, giving better precision than a dual encoder without losing document precomputation.

Which cross-encoder model should I start with?
cross-encoder/ms-marco-MiniLM-L-6-v2 from Sentence Transformers is the standard starting point for English; for managed reranking, Cohere Rerank works well in RAG pipelines.

Does LangChain support cross-encoder reranking?
Yes, both LangChain and LlamaIndex have built-in reranking steps that accept cross-encoder models as a second-stage reranker.

I write deeper technical breakdowns on search architecture, RAG systems, and AI infrastructure over at krunalkanojiya.com. The full version of this article with complete pipeline walkthroughs lives there if you want to go further.

Shopify vs Shopify Plus (2026): The Real Difference No One Talks About

Krunal Kanojiya — Wed, 27 May 2026 15:57:55 +0000

I spent three weeks helping a brand migrate from Shopify Advanced to Shopify Plus. Halfway through, I realized most of the blog posts comparing these two plans were either outdated or written by people who had never actually run a store on either. The pricing numbers were wrong. The feature lists were copy-pasted from 2023. And almost nobody mentioned that Shopify Scripts is being shut down on June 30, 2026, which makes the checkout story completely different today.

So here is the honest version.

The Short Answer

Shopify and Shopify Plus run on the same core platform. The difference is what you unlock at scale: custom checkout logic, native B2B, multi-store operations, and automation that runs without a developer on call. Whether the upgrade is worth it depends entirely on your monthly revenue and which specific ceiling you are hitting right now.

Here is where the plans live in the product lineup before you read further.

Shopify Plan Ladder (2026)
============================================
  Starter    $5/mo   — social selling only
  Basic      $39/mo  — new stores
  Grow       $105/mo — growing teams
  Advanced   $399/mo — scaling brands
--------------------------------------------
  Plus       $2,300+/mo — enterprise tier
============================================

Note: The plan formerly called "Shopify" is now called Grow in Shopify's latest pricing structure. If you see older comparisons using the name "Shopify plan," that is the same product.

Pricing: What You Actually Pay

The pricing gap between standard Shopify and Shopify Plus is not just a number. It reflects a completely different commercial model.

Standard Shopify Plans (2026)

Plan	Monthly	Annual (per month)	Online Card Rate	3rd-Party Fee
Basic	$39	$29	2.9% + 30¢	2%
Grow	$105	$79	2.7% + 30¢	1%
Advanced	$399	$299	2.5% + 30¢	0.6%

Shopify Plus Pricing (2026)

Term	Monthly Fee	Revenue Model Trigger	Cap
3-year	$2,300	0.35% above $800K/mo revenue	$40,000/mo
1-year	$2,500	0.40% above $800K/mo revenue	$40,000/mo

The variable model is the part most comparison posts skip. Once your store clears $800,000 in monthly gross merchandise value, Shopify Plus stops charging a flat fee and switches to a percentage of revenue instead. The cap at $40,000 per month means even a $100M-per-year brand does not pay more than that.

Transaction fees drop sharply on Plus as well. Standard plans charge 0.15% for third-party payment gateways, compared to 0.6% to 2% on standard tiers. For a store doing $500,000 per month through a third-party gateway, that fee reduction alone covers a significant portion of the monthly Plus cost.

The 5 Features That Actually Separate Them

1. Checkout Customization

This is the single biggest technical difference between the two plans in 2026.

Standard Shopify plans give you Checkout Extensibility with restrictions on extension count, custom JavaScript, and branding control. Shopify Plus opens the full surface: apps and UI extensions on every step of the checkout flow, Shopify Functions for custom discount and shipping logic, and the Branding API for pixel-level visual control.

Checkout Customization Gap
================================================
Standard Plans          Shopify Plus
------------------------------------------------
Basic branding          Full Branding API access
Limited extensions      Unlimited UI extensions
No custom JS            Shopify Functions (logic)
No checkout A/B         A/B testing supported
No market variants      Per-market checkout flows
================================================

One important deadline affects every Shopify merchant right now. Shopify Scripts is being permanently removed on June 30, 2026. If you or your agency built checkout logic using the Script Editor, you need to migrate that to Shopify Functions before that date. Functions are the modern replacement and they require Shopify Plus to access at full capability.

The Winter 2026 Edition also added per-market checkout customization, letting Plus merchants serve different checkout flows to different countries or B2B customer segments from a single store instance.

Callout: Checkout Extensibility as of August 28, 2025 is required for all customizations on the Thank You page and Order Status page for Plus merchants. Direct HTML and CSS editing of checkout is no longer supported on any plan.

2. B2B Commerce

Standard Shopify added foundational B2B features to all paid plans as of April 2, 2026. This is a real change worth knowing. You can now set up company accounts and custom pricing on any paid plan.

Where Plus pulls ahead is at scale. Five capabilities remain Plus-exclusive and they matter once your wholesale operation gets complex.

B2B Feature	Standard Plans	Shopify Plus
Company accounts	Yes (basic)	Yes (unlimited)
Custom price lists	Yes	Unlimited catalogs
Partial payments and deposits	No	Yes
Volume pricing at variant level	No	Yes
Sales rep permission scoping	No	Yes
Net terms	Limited	Full support

The partial payments feature changes cash flow for made-to-order and high-ticket wholesale. A Plus merchant can collect a 50% deposit at order and the remaining 50% at shipment. Standard plans cannot do this natively. For brands where B2B represents more than 20% of revenue, this feature set alone can replace a third-party wholesale tool that typically costs $500 to $2,000 per month.

3. Shopify Flow and Launchpad

Shopify Flow is Shopify Plus's no-code workflow automation engine. It uses triggers, conditions, and actions to automate operational tasks without requiring custom code. Think of it as Zapier but built directly into your store's backend with access to every internal event Shopify tracks.

Flow connects natively with Slack, Gmail, Google Sheets, Asana, Trello, and dozens of Shopify apps. Common workflows Plus merchants build include high-risk order routing, VIP customer tagging, automatic inventory alerts, B2B account onboarding sequences, and loyalty tier management.

Launchpad is the companion tool for scheduled events. You use it to automate product drops, flash sales, theme changes, and promotional campaign launches with exact timing and automated rollback. If your brand runs frequent seasonal campaigns or limited-edition releases, Launchpad removes the manual execution burden entirely.

Neither Flow nor Launchpad is available on standard Shopify plans.

4. Staff Accounts and Organizational Structure

Standard Shopify plans cap staff accounts at low numbers. Basic gives you 2, Grow gives you 5, and Advanced gives you 15.

Shopify Plus removes that ceiling completely. Unlimited staff accounts are included, and Plus adds an Organization Admin dashboard. This is a centralized management layer that sits above all your stores, letting you manage users, permissions, campaigns, and automation across your entire business from one place.

If you have a team of 20 or more people touching your store operations, the Advanced plan's 15-account limit becomes a real bottleneck before you hit any revenue threshold.

5. Expansion Stores and Multi-Store Architecture

Shopify Plus includes 10 total store instances: your primary store plus 9 expansion stores. Each expansion store is a fully functional Shopify environment with its own domain, currency, language, product catalog, and checkout configuration.

Standard plans give you one store. If you operate multiple brands, multiple regional storefronts, or both a DTC and wholesale storefront, you are either paying for multiple separate Shopify subscriptions or compromising on the experience.

Multi-Store Architecture on Plus
=============================================
  Organization Admin (top level)
  |
  |-- Primary Store (main brand, USD)
  |-- Expansion Store 1 (EU region, EUR)
  |-- Expansion Store 2 (UK region, GBP)
  |-- Expansion Store 3 (B2B wholesale)
  |-- Expansion Store 4 (new brand vertical)
  |
  (up to 10 stores total on one Plus contract)
=============================================

Each expansion store is included in the Plus contract at no additional subscription cost, though they have their own transaction fee billing.

When to Stay on Standard Shopify

Upgrading to Plus is not always the right move. Here is where standard plans are the smarter choice.

If your store generates less than $500,000 per month in revenue, the math rarely works out in favor of Plus. The fee reduction on transactions does not offset $2,300 per month in subscription cost until you are doing significant volume. Most agencies who work on migrations say the real breakeven happens somewhere between $500,000 and $700,000 per month, well before the commonly quoted $1M threshold.

You also do not need Plus if your checkout customization requirements are basic. Standard Checkout Extensibility covers the majority of use cases. The Plus-specific features matter most when you need custom discount logic at the backend, per-market checkout flows, or deeply branded checkout UI that cannot be built with standard extensions.

If your team has fewer than 15 people touching the admin, and you are operating a single storefront with no wholesale component, Advanced at $399 per month is a fully capable platform that handles up to roughly $20M in annual revenue without constraint.

When to Upgrade to Shopify Plus

The signals that point toward Plus are operational, not aspirational. Look for these in your current store.

You are hitting API rate limits regularly, especially during peak traffic. Standard plans have API caps that choke high-volume integrations with ERPs, 3PLs, or custom middleware. Plus gives you 10 times the standard API rate limits.

Your checkout conversion depends on logic that standard Checkout Extensibility cannot deliver. This includes backend discount rules, custom shipping calculations at checkout, or B2B-specific payment flows like net terms and partial deposits.

You are running or planning to run a B2B wholesale channel alongside your DTC store. Attempting to manage both on a single standard plan using apps and workarounds creates complexity that compounds as you scale. Plus handles both channels from a single admin natively.

You have multiple brands or regional storefronts and are currently paying for multiple separate Shopify subscriptions. Consolidating into one Plus contract with expansion stores is almost always cheaper and operationally simpler.

Your operational team has outgrown 15 staff accounts. Unlimited accounts plus Organization Admin makes a meaningful difference at that point.

The Migration Reality

A standard Shopify to Shopify Plus migration takes 8 to 12 weeks when the data is clean and the feature requirements are well documented. Complex integrations with ERP systems, warehouse management software, or custom checkout logic can add 4 to 8 weeks on top of that.

Budget between $50,000 and $150,000 depending on scope. Theme rebuilds, custom app development, data migration, and team training are the main cost drivers. The largest variable is whether your current checkout uses Shopify Scripts, because those workflows need to be rebuilt in Shopify Functions before June 30, 2026 regardless of plan.

Before any migration, audit your current apps for Plus compatibility. Most third-party apps from the Shopify App Store work seamlessly on Plus, but some require upgraded versions or replacements. Document all custom code and theme modifications before the transition begins.

Side-by-Side Summary

Feature	Basic	Grow	Advanced	Shopify Plus
Monthly cost	$39	$105	$399	$2,300+
Staff accounts	2	5	15	Unlimited
Checkout customization	Basic	Basic	Basic	Full (Functions + Branding API)
Shopify Flow	No	No	No	Yes
Launchpad	No	No	No	Yes
B2B features	Foundational	Foundational	Foundational	Full (Plus-exclusive scale)
Expansion stores	0	0	0	9 (10 total)
API rate limits	Standard	Standard	Standard	10x standard
3rd-party gateway fee	2%	1%	0.6%	0.15%
Organization Admin	No	No	No	Yes
Dedicated success manager	No	No	No	Yes
POS Pro locations	0	0	0	20 included

FAQs

What is the main difference between Shopify and Shopify Plus?
Shopify is built for small to mid-size businesses while Shopify Plus is an enterprise platform with advanced checkout customization, native B2B, automation tools, and multi-store architecture starting at $2,300 per month.

How much does Shopify Plus cost in 2026?
Shopify Plus starts at $2,300 per month on a 3-year contract or $2,500 per month on a 1-year contract, switching to a 0.35% revenue share model once monthly GMV exceeds $800,000, capped at $40,000 per month.

When should I upgrade from Shopify to Shopify Plus?
Most agencies find the upgrade makes financial sense between $500,000 and $700,000 in monthly revenue, though operational triggers like API limits, checkout customization needs, B2B requirements, or multi-store architecture often drive the decision before revenue thresholds.

Is Shopify Plus worth it for B2B businesses?
Yes, if your wholesale volume is significant, because Plus unlocks unlimited price catalogs, partial payments, deposits, sales rep scoping, and per-market checkout flows that standard plans cannot support natively.

What happens to Shopify Scripts in 2026?
Shopify Scripts and the Script Editor are being permanently removed on June 30, 2026. All custom checkout logic must be migrated to Shopify Functions before that deadline.

Can I downgrade from Shopify Plus back to a standard plan?
Yes. Downgrading removes access to Plus-exclusive features including B2B company accounts, Shopify Flow, Launchpad, expansion stores, full Checkout Extensibility, and elevated API limits. Your store data and products remain unaffected.

How long does a Shopify to Shopify Plus migration take?
Standard migrations take 8 to 12 weeks with clean data. Complex integrations with ERP or custom checkout logic can add 4 to 8 weeks, with migration budgets typically ranging from $50,000 to $150,000 depending on scope.

I write deeper technical breakdowns on ecommerce architecture, AI tools, and developer workflows over at krunalkanojiya.com. If this helped, that is where the next one lives.

Pricing reflects Shopify's published rates as of May 2026. Verify current rates at shopify.com/plus before making any commercial decision. Transaction fee rates may vary by region.

How to Debug React Server Components in Production

Krunal Kanojiya — Sun, 24 May 2026 11:45:16 +0000

I shipped a Next.js feature to production last year, and within ten minutes I got a Slack message with a screenshot of this:

An error occurred in the Server Components render.
The specific message is omitted in production builds to avoid
leaking sensitive details. A digest property is included on
this error instance which may provide additional details about
the nature of the error.

No component name. No stack trace. Just a digest hash. My server logs were silent because I had not set up structured logging. My error tracker had nothing because I had not wired up Sentry on the server side. I spent two hours bisecting Git commits to find a broken await call in a database query inside a Server Component.

That experience is what this guide is about. Not theory. Not official docs copy-paste. The actual workflow for tracking down RSC bugs in production, step by step.

Why Debugging RSCs is Different from Client Components

With a regular Client Component, the browser is your friend. You get DevTools, network tabs, React DevTools, console.log output right there in the console. If something crashes, you usually get a stack trace pointing to the exact line.

Server Components run on the server. The browser never sees their source code. The browser cannot step through their execution. When they throw an error, Next.js intentionally hides the message in production to protect secrets, database credentials, and internal paths from leaking to end users. All you get on the client is a digest hash.

The mental model shift is this: debugging RSCs in production is closer to debugging a Node.js API than debugging frontend JavaScript. You need server logs, distributed tracing, and error monitoring configured before the bug happens, not after.

Step 1: Understand the Digest Error System

When a Server Component throws in production, Next.js generates a deterministic digest string and logs the full error on the server. The client receives only the digest.

Here is a minimal error.tsx boundary that captures and displays the digest to your error tracking service:

// app/dashboard/error.tsx
'use client';

import { useEffect } from 'react';

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    // Send the digest to your monitoring service
    console.error('RSC Error Digest:', error.digest);

    // If using Sentry
    // Sentry.captureException(error, { extra: { digest: error.digest } });
  }, [error]);

  return (
    <div>
      <h2>Something went wrong on the server</h2>
      <p>Error ID: {error.digest}</p>
      <button onClick={reset}>Try again</button>
    </div>
  );
}

Now take that digest value and search your server logs for it. Next.js writes the full error message and stack trace to stdout tagged with the same digest. This is the bridge between what the client shows and what actually broke on the server.

Step 2: Set Up Structured Server-Side Logging

console.log inside a Server Component writes to your server's stdout. In development, you see it in the terminal. In production on Vercel, it goes to Function Logs. On a self-hosted Node server, it writes to wherever stdout is piped.

The problem with raw console.log is that it produces unstructured text. A log aggregation tool like Datadog, Logtail, or CloudWatch cannot search or filter it reliably. Swap it for structured JSON logs.

Here is a lightweight logger you can drop into any Next.js project:

// lib/logger.ts
type LogLevel = 'info' | 'warn' | 'error';

interface LogEntry {
  level: LogLevel;
  message: string;
  timestamp: string;
  component?: string;
  userId?: string;
  [key: string]: unknown;
}

export function log(
  level: LogLevel,
  message: string,
  meta: Record<string, unknown> = {}
) {
  const entry: LogEntry = {
    level,
    message,
    timestamp: new Date().toISOString(),
    ...meta,
  };

  // JSON.stringify keeps this machine-readable
  process.stdout.write(JSON.stringify(entry) + '\n');
}

And in a Server Component:

// app/products/page.tsx
import { log } from '@/lib/logger';
import { db } from '@/lib/db';

export default async function ProductsPage() {
  log('info', 'Fetching products', { component: 'ProductsPage' });

  try {
    const products = await db.products.findMany({ take: 20 });

    log('info', 'Products fetched', {
      component: 'ProductsPage',
      count: products.length,
    });

    return <ProductList products={products} />;
  } catch (err) {
    log('error', 'Failed to fetch products', {
      component: 'ProductsPage',
      error: (err as Error).message,
      stack: (err as Error).stack,
    });

    throw err; // Re-throw so the error boundary catches it
  }
}

Every log entry is a JSON object. Your log aggregator can filter by component, level, or any custom field. When a bug report comes in, you search logs by time range and component name instead of scrolling through walls of text.

Step 3: Place Error Boundaries at the Right Granularity

Next.js App Router uses error.tsx files as error boundaries. An error.tsx in a route segment catches errors from Server Components in that segment and all nested segments below it.

The common mistake is putting a single error.tsx at the root app/ level and calling it done. If your dashboard has five separate data-fetching sections, a single root boundary means the entire page goes down when one section fails.

A better pattern is segment-level isolation:

app/
  dashboard/
    error.tsx         ← catches dashboard-level errors
    analytics/
      error.tsx       ← catches analytics section errors
      page.tsx        ← fetches analytics data
    activity/
      error.tsx       ← catches activity feed errors
      page.tsx        ← fetches activity data

Each error.tsx is a Client Component ('use client') and receives the error object plus a reset function. The reset function re-renders the segment without a full page reload, which is useful for transient network failures.

// app/dashboard/analytics/error.tsx
'use client';

import { useEffect } from 'react';

export default function AnalyticsError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    // Narrow error reporting: this only fires for analytics failures
    reportError({ digest: error.digest, section: 'analytics' });
  }, [error]);

  return (
    <div className="analytics-error">
      <p>Analytics failed to load.</p>
      <button onClick={reset}>Retry</button>
    </div>
  );
}

Granular error boundaries mean a broken analytics widget does not take down the activity feed. The user sees a partial page with a retry button instead of a blank screen.

Step 4: Debug Hydration Mismatches at the Source

Hydration errors happen when the HTML the server sends does not match what React renders on the client during the first paint. The browser console shows something like:

Hydration failed because the initial UI does not match
what was rendered on the server.

The three most common causes are dates/timestamps, random IDs, and browser-only APIs accessed during render.

Dates computed at render time are a classic trap:

// WRONG - server and client compute different timestamps
export default async function Page() {
  const renderedAt = new Date().toLocaleTimeString(); // differs server vs client
  return <p>Rendered at: {renderedAt}</p>;
}

// CORRECT - move time display to a Client Component
'use client';

import { useState, useEffect } from 'react';

export function RenderedAt() {
  const [time, setTime] = useState<string>('');

  useEffect(() => {
    setTime(new Date().toLocaleTimeString());
  }, []);

  return <p>Rendered at: {time || '...'}</p>;
}

Browser APIs like window, localStorage, or navigator are undefined during server render. Accessing them directly inside a component that Next.js tries to prerender causes a mismatch.

// WRONG - window is undefined on the server
function ThemeToggle() {
  const isDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
  return <button>{isDark ? 'Light mode' : 'Dark mode'}</button>;
}

// CORRECT - read browser APIs inside useEffect
'use client';

import { useState, useEffect } from 'react';

function ThemeToggle() {
  const [isDark, setIsDark] = useState(false);

  useEffect(() => {
    setIsDark(window.matchMedia('(prefers-color-scheme: dark)').matches);
  }, []);

  return <button>{isDark ? 'Light mode' : 'Dark mode'}</button>;
}

For third-party components that you cannot easily refactor, Next.js provides next/dynamic with ssr: false:

// app/dashboard/page.tsx
import dynamic from 'next/dynamic';

const ChartWidget = dynamic(() => import('@/components/ChartWidget'), {
  ssr: false,
  loading: () => <div>Loading chart...</div>,
});

export default function Dashboard() {
  return (
    <main>
      <h1>Dashboard</h1>
      <ChartWidget />
    </main>
  );
}

The ssr: false option tells Next.js to skip server rendering for this component entirely. No server render means no hydration mismatch.

Step 5: Use try/catch Strategically in Server Components

Unlike Client Components where React's error boundary catches render errors automatically, Server Components need explicit try/catch blocks for non-render code like data fetching. Server Actions in particular have no automatic centralized error handler.

Here is a pattern that logs the error, records context, and falls back gracefully:

// app/user/[id]/page.tsx
import { log } from '@/lib/logger';
import { notFound } from 'next/navigation';

async function getUser(id: string) {
  try {
    const res = await fetch(`${process.env.API_URL}/users/${id}`, {
      next: { revalidate: 60 },
    });

    if (res.status === 404) return null;

    if (!res.ok) {
      throw new Error(`API responded with ${res.status}`);
    }

    return res.json();
  } catch (err) {
    log('error', 'getUser failed', {
      userId: id,
      error: (err as Error).message,
    });
    return null;
  }
}

export default async function UserPage({
  params,
}: {
  params: { id: string };
}) {
  const user = await getUser(params.id);

  if (!user) notFound();

  return <UserProfile user={user} />;
}

This approach keeps the page render clean. The data fetching function handles its own errors, logs them with context, and returns null instead of throwing. The page component then decides what to render based on the result.

For Server Actions where you absolutely must surface errors back to the client:

// app/actions/createPost.ts
'use server';

import { log } from '@/lib/logger';

export async function createPost(formData: FormData) {
  try {
    const title = formData.get('title') as string;

    if (!title || title.length < 3) {
      return { error: 'Title must be at least 3 characters' };
    }

    const post = await db.post.create({ data: { title } });

    return { success: true, postId: post.id };
  } catch (err) {
    log('error', 'createPost failed', {
      error: (err as Error).message,
    });

    return { error: 'Failed to create post. Please try again.' };
  }
}

Server Actions swallow exceptions by default when called from Client Components. Returning a typed result object with an error field is cleaner and more predictable than letting errors bubble up.

Step 6: Add OpenTelemetry for Distributed Tracing

Structured logs tell you what went wrong. Distributed traces tell you why and where in the request lifecycle it went wrong. For a Next.js app with Server Components, OpenTelemetry gives you end-to-end visibility from the browser request through server component execution to the database query.

Next.js has built-in OpenTelemetry support through the instrumentation.ts file:

npm install @vercel/otel @opentelemetry/api

// instrumentation.ts (in the root of your project)
import { registerOTel } from '@vercel/otel';

export function register() {
  registerOTel({
    serviceName: 'my-nextjs-app',
  });
}

Next.js automatically creates spans for Server Component renders, data fetches, and API route handlers when OpenTelemetry is registered. You can add custom spans for your own data-fetching functions:

// lib/db.ts
import { trace } from '@opentelemetry/api';

const tracer = trace.getTracer('database');

export async function queryProducts(limit: number) {
  return tracer.startActiveSpan('db.queryProducts', async (span) => {
    try {
      span.setAttribute('db.limit', limit);

      const products = await db.product.findMany({ take: limit });

      span.setAttribute('db.result_count', products.length);
      span.end();

      return products;
    } catch (err) {
      span.recordException(err as Error);
      span.setStatus({ code: 2, message: (err as Error).message }); // SpanStatusCode.ERROR = 2
      span.end();
      throw err;
    }
  });
}

Point the exporter at any OpenTelemetry-compatible backend. Grafana Tempo, Honeycomb, and Dash0 all work with standard OTLP endpoints:

# .env.local
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-otel-backend.com
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer your-token

Now when a production error happens, you can pull up the trace for that specific request and see exactly which span failed, how long it took, and what database query or API call was running at the time.

Step 7: Wire Up Sentry for Production Error Tracking

OpenTelemetry is great for performance tracing. Sentry is better for error capture, grouping, and alerting. The two complement each other well. For Next.js, Sentry covers Server Components, Client Components, Server Actions, and edge middleware with one setup:

npx @sentry/wizard@latest -i nextjs

The wizard creates sentry.client.config.ts, sentry.server.config.ts, and sentry.edge.config.ts automatically. A basic server config looks like this:

// sentry.server.config.ts
import * as Sentry from '@sentry/nextjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,

  // Capture 100% of errors, 10% of performance traces in production
  tracesSampleRate: 0.1,

  environment: process.env.NODE_ENV,

  // Attach the digest to every server-side error event
  beforeSend(event) {
    return event;
  },
});

To add custom context to your Server Component errors:

// app/orders/page.tsx
import * as Sentry from '@sentry/nextjs';

export default async function OrdersPage({
  searchParams,
}: {
  searchParams: { status?: string };
}) {
  return Sentry.withServerActionInstrumentation(
    'fetchOrders',
    {
      formData: null,
      recordResponse: true,
    },
    async () => {
      const orders = await fetchOrders(searchParams.status);
      return <OrderList orders={orders} />;
    }
  );
}

Once Sentry is running in production, every Server Component error comes in with the full stack trace, the request URL, the user's session (if you configure it), and a replay of what happened before the crash. The digest from your error.tsx boundary maps directly to the Sentry issue ID, so you can go from a user complaint to the exact error in seconds.

Step 8: Decode Minified Stack Traces with Source Maps

Production builds are minified. Stack traces point to line 1 of a compressed bundle, which is useless. Source maps translate those minified references back to your original TypeScript source.

For Sentry, the wizard handles source map uploads automatically during next build. For manual setups or other error trackers:

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  // Generate source maps in production
  productionBrowserSourceMaps: true,

  // If you use Sentry, its webpack plugin handles upload automatically
};

module.exports = nextConfig;

If you want source maps available without making them public, upload them to your error tracker and block access via your CDN. Sentry, Datadog, and LogRocket all support private source map uploads.

# Upload source maps to Sentry manually
npx @sentry/cli sourcemaps upload \
  --org your-org \
  --project your-project \
  .next/static/chunks

With source maps in place, a production error that previously showed at <anonymous>:1:34523 now shows at ProductsPage (app/products/page.tsx:42:7).

Step 9: A Practical Debugging Checklist

When something breaks in production and you have no idea where to start, run through this sequence.

First, get the digest. Check your error.tsx boundary output or your Sentry dashboard for the error digest or ID. This is your anchor.

Second, search server logs. Search your log aggregator for the digest value. Next.js logs the full error message paired with the digest on the server side. If you have structured logging set up from Step 2, filter by component and the time window around the first occurrence.

Third, check the request trace. If you have OpenTelemetry, look up the trace for the request that triggered the error. Find the failing span, check its attributes, and look at any database queries or external API calls that preceded it.

Fourth, reproduce locally. If the error is data-related, try to reproduce it with the same inputs. Add console.log in the specific Server Component and run next build && next start locally to get production behavior without minification. You can also set NODE_ENV=production locally while keeping source maps active.

Fifth, check caching. A surprisingly large number of Server Component bugs in production are caching-related. A component works in development where cache: 'no-store' is the default for fetch, and breaks in production where Next.js enables data cache by default. Verify your fetch options:

// Force fresh data on every request
const data = await fetch(url, { cache: 'no-store' });

// Or use Next.js-specific revalidation
const data = await fetch(url, { next: { revalidate: 60 } });

Common RSC Bugs and Their Fixes

Importing a Client-only library in a Server Component causes a runtime error because the library tries to access window or document on the server.

// WRONG - chart.js accesses window internally
import { Chart } from 'chart.js';

export default async function StatsPage() {
  return <Chart data={data} />; // crashes on server
}

// CORRECT - wrap in dynamic import with ssr: false
const Chart = dynamic(() => import('@/components/Chart'), { ssr: false });

Passing non-serializable props from Server to Client Components causes a serialization error. Server Components can only pass JSON-serializable values to Client Components: strings, numbers, plain objects, arrays. Functions, class instances, and Promises are not serializable.

// WRONG - passing a class instance
const user = new User({ id: 1, name: 'Krunal' }); // User class with methods
return <ClientProfile user={user} />;

// CORRECT - pass a plain object
return <ClientProfile user={{ id: user.id, name: user.name }} />;

Async Server Components without proper error handling that hit a network timeout silently return undefined instead of throwing, resulting in a blank UI with no error logged.

// WRONG - no timeout, no error handling
const data = await fetch(externalApiUrl).then(r => r.json());

// CORRECT - add timeout and handle failure
async function fetchWithTimeout(url: string, ms = 5000) {
  const controller = new AbortController();
  const id = setTimeout(() => controller.abort(), ms);

  try {
    const res = await fetch(url, { signal: controller.signal });
    clearTimeout(id);

    if (!res.ok) throw new Error(`HTTP ${res.status}`);

    return res.json();
  } catch (err) {
    clearTimeout(id);
    log('error', 'Fetch failed', { url, error: (err as Error).message });
    return null;
  }
}

FAQs

Why are React Server Component errors hidden in production?
Next.js intentionally strips error messages in production builds to prevent leaking sensitive server-side details to the client; only a digest hash is shown instead.

How do I read the digest error from a React Server Component?
Search your server logs for the digest value shown in the browser error — Next.js logs the full error message and stack trace on the server side paired with that digest.

Can I use React DevTools to debug Server Components?
React DevTools can show Server Components in the component tree, but it cannot access their server-side execution, state, or data fetching — you need server-side logging or OpenTelemetry for that.

What is the best error tracking tool for Next.js Server Components?
Sentry with the @sentry/nextjs SDK covers client components, server components, server actions, and edge middleware in one install.

How do I fix hydration mismatch errors caused by Server Components?
Ensure that any value computed during server render — like dates, random IDs, or browser-only APIs — is either moved to a Client Component using useEffect or wrapped with suppressHydrationWarning when a mismatch is expected and harmless.

Wrapping Up

RSC debugging in production is not easy, and that is not entirely the developer's fault. The architecture is genuinely new. The tooling is still catching up. The browser DevTools were built for client-side code, and that is not where Server Components live.

What makes the difference is preparation. Set up structured logging before you deploy. Add error boundaries at the right granularity before your users hit them. Wire up Sentry and OpenTelemetry before your first production incident, not during it.

When the next digest error lands in your Slack channel, you will have the logs, the traces, and the source maps to go from "something broke" to "line 42 in page.tsx" in minutes instead of hours.

How to Optimize LLM Inference with KV Caching

Krunal Kanojiya — Thu, 14 May 2026 03:24:25 +0000

Large Language Models (LLMs) are the engines behind tools like ChatGPT. They are very smart, but they can be slow. If you want to build fast AI tools, you need to know how to optimize them. The most important way to do this is with KV Caching.

This guide will show you how KV Caching works and the best ways to set it up.

The Big Problem: The Re-Reading Bottleneck

When an AI writes a sentence, it predicts one word at a time. To pick the next word, it must look at every word it already wrote.

Think of it like this. Every time you write a new word in a story, you have to stop and read the whole story from the start. If your story is very long, you spend more time reading than writing. This makes the AI slow and uses too much power.

According to this technical report from NVIDIA, this "re-reading" is the biggest reason for slow AI.

The Solution: What is KV Caching?

KV Caching is like keeping a notepad next to the AI. Instead of re-reading everything, the AI writes down notes about every word it sees. These notes are called Keys (K) and Values (V).

Keys: These help the AI understand how words relate.
Values: These hold the information for each word.

When the AI writes a new word, it just looks at its notepad. It does not go back to the start. To see the math behind these notes, you can check out this KV cache explained guide for a full technical breakdown.

How to Optimize Your AI with KV Caching

To actually use and optimize this system, you should follow these three steps.

1. Use an Optimized Library

You do not have to build a cache from scratch. Most developers use tools that have caching built in.

Hugging Face Transformers: This is a popular tool for AI. When you use the generate() function, you should set use_cache=True. This tells the AI to start saving its notes.
vLLM: This is a newer tool made for high speed. It uses a special trick called PagedAttention. This trick manages the memory so the cache does not get messy.

2. Shrink Your Cache (Quantization)

The KV Cache lives in the VRAM (the video memory) of your computer. If your cache is too big, the computer will run out of space.

To optimize this, you can use Quantization. This means you store the notes using smaller numbers. Instead of using a lot of memory for each word, you use just enough. This allows the AI to handle much longer conversations.

3. Use Better AI Designs (GQA)

Modern AI models like Llama 3 use a trick called Grouped-Query Attention (GQA).

In older models, every "brain part" of the AI had its own set of notes. In GQA, many parts of the AI share the same notes. This makes the KV Cache much smaller without making the AI less smart. According to research from Google, this is one of the best ways to speed up inference.

The Two Steps of the Process

When you optimize your AI, it will go through these two phases smoothly:

The Prefill Phase: The AI reads your prompt and fills up the notepad (the cache) for the first time.
The Decoding Phase: The AI writes its answer word by word. It only does the math for the newest word. It saves that info in the cache and moves to the next one.

According to data from Hugging Face, the Decoding Phase is where users notice the most speed. Without a good cache, the AI would get slower with every word it writes.

Summary Checklist for Developers

Enable Caching: Always turn on the cache in your code settings.
Monitor VRAM: Keep an eye on your memory so your cache does not overflow.
Use vLLM: For production apps, use libraries that handle memory for you.
Choose GQA Models: Use models that share "Keys" and "Values" to save space.

Conclusion

Optimizing an LLM is all about being smart with memory. KV Caching stops the AI from doing the same work over and over. By using the right libraries and shrinking your data, you can make an AI that feels fast and smart.

Learning how to manage the KV Cache is the best way to become an expert in building AI tools for the real world.

Sam Altman Dropped Some Hard Truths About AI

Krunal Kanojiya — Sun, 01 Feb 2026 06:45:30 +0000

On January 27, 2026, Sam Altman sat down with a room full of nervous developers in San Francisco. No slides. No polished pitch. Just him answering the questions everyone's been afraid to ask out loud.

Things like: Is my coding career over? How do I compete if anyone can build software now? What happens next?

He didn't sugarcoat it. Here's what he said, broken down into things you can actually do something about.

1. Coding Jobs Aren't Dying — They're Changing

Everyone's panicking that AI will replace developers. Altman pushed back on this.

Think about it this way: cars made driving faster, but people didn't drive less. They drove more. The same thing is happening with software. AI makes building faster, so the world is going to want more software, not less.

What changes is what your job looks like. You'll spend less time typing code and more time telling the AI what to build and why. The job title stays the same. The actual work looks completely different.

The shift: We're going from "writing code" to "directing outcomes."

2. The Real Problem Isn't Building — It's Getting Noticed

Back in the day, the hard part of starting a company was actually making the product. You needed developers, servers, months of work.

Now? A single person can ship a product in a weekend.

So what's the problem? Everyone else can too. The market is flooded.

Altman's take: the bottleneck isn't the product anymore. It's getting people to care about it. Anyone can build something. Very few people can make something that people actually pay attention to.

What this means for you: Stop worrying so much about your tech stack. Focus on who you're building for and how they'll find you. If you can't prove people want it before you build it, you're just wasting your time.

3. Software Is About to Get Weirdly Personal

Right now, software is one-size-fits-all. Microsoft Word looks the same on your screen as it does on mine.

Altman thinks that's about to end. He sees a future where software reshapes itself around you — not the other way around.

Picture a project management tool that doesn't just let you customize a few settings, but actually rearranges its entire layout based on how you work. Every single time.

The opportunity: Don't build rigid tools. Build tools that can adapt on the fly based on what the user actually needs in that moment.

4. AI Is Making Things Cheaper — But Not Everyone Wins

Here's the uncomfortable part. AI is driving the cost of knowledge and digital work down toward zero. That sounds great, right?

It is — if you're the one using that leverage. A single person with the right AI tools can now do what a small team used to do.

But if you're just selling your hours? That's a shrinking market. The people who benefit most are the ones who own the tools or know how to use them at scale.

The lesson: You need to be on the side that's using the leverage, not the side that is the leverage.

5. By 2027, AI Thinking Will Be Basically Free

Altman got specific here. The cost of running AI models is about to drop — potentially 100x by the end of 2027.

But there's a catch. Speed and cost are becoming a trade-off. Background tasks? Use the cheap, slower models. Need an answer right now in a live product? That'll cost a bit more.

The split: Cheap and slow for batch work. Fast and premium for anything the user is waiting on.

6. The Biggest Risk Right Now Is Bio-Safety

This was the serious part of the talk. Altman was blunt: the scariest thing AI can do right now isn't writing bad code or making deepfakes.

It's biology. Current models already know too much about how biological systems work, and that's dangerous in the wrong hands.

His take on how to handle it? Stop trying to prevent AI from ever knowing dangerous things — that ship has sailed. Instead, build systems and policies that can withstand bad actors. Think fire codes, not fire bans.

7. What You Should Actually Be Learning

For kids? Altman said keep them away from AI for now. Let them play, move around, interact with real people and real objects. The basics still matter.

For the rest of us, the game has changed. Memorizing syntax and following tutorials isn't going to cut it anymore. What matters now is:

Can you make things happen? Not just write code — actually get results in the real world.

Can you recover when AI gets it wrong? Because it will. Knowing how to spot and fix AI mistakes is a real skill.

Can you unlearn fast? The tools change every few months. If you're still clinging to how things worked last year, you're already behind.

8. How Companies Are Actually Hiring Now

OpenAI is still hiring, but the way they test candidates has flipped completely.

Old way: "Here's a problem. You have two weeks. Go."

New way: "Here's that same problem. You have 20 minutes. Use every AI tool you can."

If you're avoiding AI tools because it feels like cheating, you're not being humble — you're making yourself hard to hire. Nobody cares how you solved it. They care how fast.

"But AI Still Gets Things Wrong…"

Yeah, it does. Altman didn't pretend otherwise.

Here's the math problem though. If an AI is 99% accurate on any single step, but your task has 100 steps, the chance of getting through all of them perfectly is actually pretty low. That's just how probability works.

So the next big push isn't making AI smarter. It's making it more reliable — consistently right over long, complex tasks. That's what GPT-5 and the models after it are focused on.

Don't build your whole strategy around the assumption that AI will always be this flaky. It's improving faster than almost anything else in tech history.

So What Do You Actually Do Right Now?

Look at your week. What are you still doing by hand out of habit or pride? That's your first target to automate.

Learn how to chain tools together. One AI doing one thing is fine. Knowing how to connect three of them to solve a bigger problem? That's the real skill.

Talk to people before you build. Building is cheap now, which means the market is noisy. Prove someone wants what you're making before you write a single line of code.

Get better at the human stuff. Negotiation, creativity, empathy, leadership — these are the hardest things to automate, and they matter more than ever.

Time yourself. Seriously. Try doing your normal daily work 50% faster with AI tools. If you can't, you haven't figured out how to use them right yet.

The future isn't something coming down the road. It's already here. The only real question is whether you're going to be the person getting automated — or the person doing the automating.

What's one thing you could automate this week but haven't? Drop it in the comments.

React Native vs Native Android Cost: Which One Saves You More Money?

Krunal Kanojiya — Fri, 30 Jan 2026 08:36:24 +0000

At a Glance: React Native costs less upfront and works for both iOS and Android. Native Android costs more at first but runs better for complex apps. Your final bill depends on what your app needs to do, not just which tool you pick.

The Money Question Everyone Asks

You want to build an app. The first question: how much will it cost?

React Native usually wins on price. One codebase works on iOS and Android. Smaller teams build faster. Perfect for startups testing ideas without burning cash.

Native Android costs more. You need separate code and specialized developers. But you get better hardware control and stability. Good for apps where performance matters most.

Let's break down the real costs so you can pick what fits your budget.

What You're Actually Paying For

App costs aren't just about writing code. Money goes to different buckets:

UI/UX Design

How your app looks and feels. Good design keeps users around. Bad design sends them running to competitors.

Frontend Development

The part users touch. Buttons, screens, animations. Costs rise with complex features and multiple platforms.

Backend and APIs

The engine under the hood. Handles data, connects to servers, talks to payment systems. Real-time features and heavy data needs drive up costs here.

Third-Party Integrations

Payment processing, maps, social logins. These services charge fees or take usage cuts.

Testing and QA

Finding bugs before users do. More features mean more testing. More devices mean more work.

App Store Deployment

Getting your app on Google Play or Apple's App Store. Includes prep work and store fees.

Ongoing Maintenance

Updates, bug fixes, new features. Never stops. Popular apps with many users cost more to maintain.

React Native: Where Your Money Goes

React Native cuts costs by using one codebase for both platforms. Here's how that saves you money:

Faster MVP Delivery

Build once, run everywhere. Get your minimum viable product out fast. Start collecting user feedback sooner. Time is money.

Lower Hiring Cost

Hire React Native developers instead of separate iOS and Android teams. One framework, one skill set. Cuts labor costs nearly in half.

No Parallel Development

Two native teams mean double coordination headaches. React Native uses one team building one thing. Simpler. Cheaper.

Native Android: What Drives the Price Up

Building native means platform-specific code in Kotlin or Java. Costs more because:

Higher Developer Specialization

Native Android developers need deep skills. Kotlin or Java expertise. Android design patterns. APIs and tools specific to Google's ecosystem. Specialized talent costs more.

Better Access to Android APIs

Direct connection to Android's core features. Custom notifications, background services, complex animations. Apps needing these features benefit from native development.

Separate Cost if iOS is Added

Want iOS too? Build a whole new app in Swift or Objective-C. Separate codebase, separate team, doubled development budget.

Initial Development: Head to Head

React Native wins the starting race.

MVP Timelines

React Native ships MVPs faster. One small team handles both platforms. Perfect for quick launches and early feedback.

Team Requirements

React Native needs one development team. Native Android needs two teams if you want iOS. Simple math: fewer people means lower costs.

Speed vs Quality Trade-off

React Native updates both platforms at once. Fast iterations. Native Android needs deeper work but delivers better performance. Higher quality costs more time and money.

What Developers Cost You

US market rates (2025 data):

React Native Developer

Annual: $90,000 to $130,000
Freelance: $50 to $100 per hour
15-30% cheaper than Native Android

Native Android Developer

Annual: $110,000 to $150,000
Freelance: $70 to $120 per hour

React Native developers are easier to find and cost less. Native Android specialists command premium rates.

The Costs Nobody Talks About

Hidden expenses sneak up on you:

Technical Debt

Rush your code and pay later. Bad decisions early make improvements expensive down the road.

Poor Architecture

Messy code structure makes updates painful. New features take longer. Costs pile up.

Performance Refactors

Slow app? Major fixes cost serious money. Better to build it right the first time.

Developer Handovers

Switching developers mid-project causes delays and bugs. Fixing these mistakes costs extra.

Store Policy Changes

Apple and Google update rules regularly. Your app needs updates to stay compliant. Budget for this.

Side by Side Comparison

Cost Factor	React Native	Native Android
Initial Development	Lower (shared codebase)	Higher (separate platform code)
Hiring	Cheaper, more available	Expensive, specialized skills
Performance Fixes	Higher for complex features	Lower, built for Android
Maintenance	Lower, one codebase	Higher, separate codebases
Scaling	Cheaper across platforms	More expensive for Android-only

Making Your Choice

Need a quick prototype on a tight budget? React Native makes sense. Great for cross-platform apps.

Building something complex with advanced features? Native Android delivers better performance and stability for Android-focused apps.

Your choice depends on:

How fast you need to launch
Your total budget
Performance requirements
Long-term plans (one platform or many)

Wrapping Up

Both options work. React Native saves money upfront and ships faster. Native Android costs more but runs better for demanding apps.

Pick based on your needs, not trends. Know your budget. Understand your timeline. Match the tool to your goals.

Need help deciding? Talk to developers who know both. Get estimates. Make an informed choice that fits your business.

Still have questions? The right framework for your app depends on your specific situation. Consider what matters most: speed to market, budget limits, or app performance.

How Spotify Splits Its Recommendation Systems (And Why It Matters)

Krunal Kanojiya — Thu, 29 Jan 2026 08:54:53 +0000

As more companies use AI to make decisions, they face a tricky problem. The same system is asked to do two different jobs at once. This causes issues, especially for big platforms like Spotify.

Spotify learned this the hard way. They built systems to recommend music and podcasts. But those systems had to handle two tasks:

Serve users in real time - Fast, stable, reliable
Run experiments to improve - Flexible, careful, willing to fail

These jobs don't mix well. So Spotify split them apart.

Why Two Jobs Need Two Systems

Your recommendation engine needs to be fast. When a user opens the app, they expect results now. Any delay or crash hurts the experience.

Your experiment system needs to be thorough. It tests ideas, compares results, and learns from failures. Speed matters less than getting the right answer.

When you mix these systems, both suffer:

Experiments slow down your app
Production bugs mess up your test data
Changes become risky
Teams step on each other's work

Spotify kept hitting these problems. So they made a choice: separate the systems completely.

What This Split Looks Like

Personalization systems handle live requests. They focus on:

Low delay times
High uptime
Stable performance
Serving millions of users

Experiment systems run tests offline. They focus on:

Accurate measurements
Clear tracking
Safe testing
Good data quality

When you separate them, each system gets better at its job. Experiments can change often without breaking production. Production stays stable while new ideas get tested.

If an experiment fails, users never see it. If production has an issue, your experiment data stays clean.

How Models Move to Production

Spotify doesn't push models straight to users. First, they go through an evaluation path:

Build a model in the experiment system
Test it against current models
Check the results carefully
Debate if it actually helps
Only then move it to production

This matters more as AI gets harder to understand. Small changes can cause big effects. Often you only find problems after users notice them.

The split gives teams time to think. They can ask hard questions:

Did this change actually help?
Did it hurt something we didn't measure?
Are we sure we understand what happened?

The Real Challenge: Coordination, Not Models

The hard part isn't building better models. It's getting people to work together.

Splitting systems forces teams to agree on:

How data moves between systems
Who owns what
What tools everyone uses
How to track and review changes

This takes work. It adds process. It slows things down in places where speed used to feel important.

But that slowdown helps. It creates space to ask if you're building the right thing. It lets teams test ideas without committing to them. It gives clearer signals about what's safe to ship.

Why This Matters More Now

As AI takes on more work, you need better ways to check if it's doing the right thing. Models are black boxes. Small changes can have wide effects.

By keeping experiments separate, Spotify can:

Catch issues before users see them
Keep a clear record of decisions
Roll back changes easily
Build trust in what they ship

This isn't just about having a staging environment. It's about building systems that support disagreement, measurement, and learning.

What You Can Take Away

You probably don't run Spotify-scale systems. But the lesson still applies.

Many teams run experiments inside production because it feels simpler. At first, it is. Over time, that simplicity breaks down:

Changes get harder to explain
Rollbacks become scary
You lose confidence in results

Separating experiments from serving takes upfront work. But it pays off:

You get clearer answers
Teams make better decisions
Risk goes down
Trust goes up

As AI systems take on more responsibility, these things matter. The infrastructure you build shapes how your team behaves. When systems favor learning over speed, people make better long-term choices.

That might be the most practical lesson here.

DEV Community: Krunal Kanojiya

How to Use Type Annotations to Explicitly Type Variables in TypeScript

TLDR

What is a Type Annotation?

The Basic Syntax

How to Annotate Variables

Annotating constants

How to Annotate Function Parameters

Multiple parameters with different types

How to Annotate Function Return Types

The void return type

Common return type annotations

How to Annotate Arrays

The alternative Array<type> syntax

How to Annotate Objects

Inline object annotation

Optional properties in objects

How to Annotate Union Types

How to Annotate with null and undefined

What Happens to Annotations After Compilation?

Annotation vs Inference: When to Write It Yourself

Full Example Putting It All Together

Common Annotation Mistakes

FAQ

What You Learned

How to Use Primitive Types in TypeScript: string, number, and boolean

TLDR

What Are Primitive Types?

How to Use the string Type

Basic string annotation

Three ways to write strings

What TypeScript catches with strings

Common string operations TypeScript knows about

How to Use the number Type

Basic number annotation

Special number values

Number formats TypeScript supports

What TypeScript catches with numbers

A common mistake: numbers as strings

How to Use the boolean Type

Basic boolean annotation

Booleans from comparisons

Booleans in conditions

What TypeScript catches with booleans

How to Use the null Type

null on its own

null combined with other types

Working safely with null values

How to Use the undefined Type

The difference between null and undefined

How to Use the bigint Type

When to use bigint

What you cannot do with bigint

How to Use the symbol Type

When to use symbol

Type Annotations vs Type Inference

All 7 Primitive Types at a Glance

Quick Comparison of All Primitive Types

Common Mistakes with Primitive Types

FAQ

What You Learned

How to Enable Strict Mode and Why You Should Always Use It

TLDR

What is Strict Mode in TypeScript?

How to Enable Strict Mode

What Does strict: true Actually Turn On?

Why Each Flag Matters (With Code Examples)

1. strictNullChecks — Stop Null Crashes

2. noImplicitAny — No Hidden any Types

3. strictPropertyInitialization — Class Properties Must Be Set

4. useUnknownInCatchVariables — Safe Error Handling

5. strictBindCallApply — Type-Safe Function Methods

6. noImplicitThis — Clear this Typing

Two Extra Flags Worth Adding

noUncheckedIndexedAccess

noImplicitOverride

The Full Recommended Strict Config

What the Same Code Looks Like Without and With Strict Mode

How to Enable Strict Mode on an Existing Project

Does Strict Mode Change the JavaScript Output?

The `void` return type

The alternative `Array<type>` syntax

How to Annotate with `null` and `undefined`

How to Use the `string` Type

How to Use the `number` Type

How to Use the `boolean` Type

How to Use the `null` Type

`null` on its own

`null` combined with other types

Working safely with `null` values

How to Use the `undefined` Type

The difference between `null` and `undefined`

How to Use the `bigint` Type

When to use `bigint`

What you cannot do with `bigint`

How to Use the `symbol` Type

When to use `symbol`

What Does `strict: true` Actually Turn On?

1. `strictNullChecks` — Stop Null Crashes

2. `noImplicitAny` — No Hidden `any` Types

3. `strictPropertyInitialization` — Class Properties Must Be Set

4. `useUnknownInCatchVariables` — Safe Error Handling

5. `strictBindCallApply` — Type-Safe Function Methods

6. `noImplicitThis` — Clear `this` Typing

`noUncheckedIndexedAccess`

`noImplicitOverride`

`--listFiles`

`--showConfig`

How to Set the `target` Option

How to Set the `module` Option

How to Set `outDir` and `rootDir`

How to Configure `include` and `exclude`

How to Set Up Path Aliases with `paths`

How to Add `lib` for Extra Type Definitions