DEV Community: Krunal Kanojiya

Top Shopify Agencies in the US for 2026 (A Developer's Honest Take)

Krunal Kanojiya — Mon, 29 Jun 2026 10:04:16 +0000

I've seen good Shopify stores break because of bad agency choices.

Not bad code. Not bad ideas. The agency just was not the right fit for what the brand actually needed. And when you're a developer or a CTO making that call, the cost of getting it wrong lands squarely on your sprint.

By 2026, the Shopify ecosystem in the US has matured significantly. Building a high-performing Shopify store requires more than templates. It demands technical expertise, conversion-focused design, and strategic execution. There are hundreds of agencies claiming to be the best. Most of them are decent. A handful are genuinely excellent.

This post cuts through the noise.

Why Picking a Shopify Agency Feels Harder Than It Should

Here's the frustrating reality. Most agency websites look nearly identical. Everyone claims "conversion-focused builds," "scalable architecture," and "proven results." The language blurs together fast.

What actually separates agencies in 2026 is where their depth sits. Some are strong in custom Shopify app development. Others live and breathe CRO. Some are enterprise-grade and charge accordingly. A few are perfect for mid-market DTC brands that need speed without bloat.

US agencies have a strong understanding of consumer behavior, payment systems, and compliance requirements, which enables them to build not just functional stores but highly optimized, conversion-focused eCommerce solutions.

The question is not "which agency is best." It's "which agency is best for your specific situation."

What to Look for Before You Even Open a Proposal

Before evaluating any agency, get clear on three things:

Your project size and budget. Mid-market implementations typically range from $25,000 to $100,000 for comprehensive solutions, while enterprise Shopify Plus projects can exceed $100,000 for complex custom implementations.
Your platform maturity. Are you launching fresh, migrating from WooCommerce or Magento, or optimizing an existing Shopify Plus store?
Whether you need ongoing support. Some agencies are best for project-based work. Others shine on monthly retainers where they act as an embedded dev team.

With that in mind, here are the agencies worth your attention in 2026.

Top Shopify Agencies in the US for 2026

1. Lucent Innovation

Location: US-serving (Remote-first) | Best for: Custom Shopify development, Shopify Plus builds, API integrations, and eCommerce transformation

If you are looking for a team that treats your Shopify store as a product rather than a project, Lucent Innovation is worth a serious look.

They specialize in custom Shopify and Shopify Plus development for US-based brands, bringing a strong engineering foundation alongside a real focus on performance and scalability. Where a lot of agencies stop at theme customization, Lucent Innovation goes deeper, handling complex third-party API integrations, custom app development, and full eCommerce architecture builds.

What sets them apart is the combination of technical depth and product thinking. The team is not just building what you spec out. They are helping you think through what should be built and why. For CTOs and product teams that want a development partner who communicates clearly and ships reliably, that is a meaningful difference.

Their work spans industries including fashion, lifestyle, and consumer goods, with a consistent track record of high-performance Shopify storefronts that scale as traffic and catalog complexity grow.

Services: Custom Shopify development, Shopify Plus, third-party integrations, API development, performance optimization, UI/UX design, eCommerce consulting

Worth exploring if: You need a technical partner for a mid-to-large Shopify build where cookie-cutter solutions will not cut it.

2. SmartSites

Location: Paramus, New Jersey | Best for: SEO-driven Shopify builds, PPC, and performance marketing

SmartSites is a certified Shopify Partner based in Paramus, New Jersey, specializing in website design, SEO, PPC advertising, and social media marketing. They have earned over 1,000 five-star reviews, which is not a number most agencies get close to.

When enterprise brands and small businesses need eCommerce platforms that drive results, SmartSites builds Shopify stores with integrated SEO, PPC, and conversion optimization.

SmartSites makes the most sense if your store needs solid technical SEO baked in from day one alongside the build itself. Their entry-level project threshold is low compared to most premier partners, which gives smaller brands access to real Shopify expertise without enterprise-level pricing.

Services: Custom Shopify design and development, SEO, CRO, PPC, theme customization, migration services

3. Lounge Lizard

Location: New York City, NY | Best for: Brand-forward Shopify development and design-led experiences

Lounge Lizard brings a Madison Avenue advertising approach to Shopify development. They are a national digital agency that focuses heavily on brand perception and user experience, creating visually stunning, award-winning storefronts perfect for brands where aesthetics and storytelling drive sales.

They have been around long enough to have built deep experience across every stage of Shopify's evolution. Lounge Lizard is a reputable agency with 28 years of experience known for delivering strategic, design-driven digital solutions that help brands grow and compete effectively.

If your product is one where customers buy with their eyes first, Lounge Lizard understands that better than almost anyone on this list.

Services: Custom Shopify web design, development, digital marketing, brand strategy

4. Coalition Technologies

Location: Los Angeles, CA | Best for: Large-scale enterprise Shopify projects, technical SEO

Coalition Technologies is a US-based Shopify development agency known for handling large-scale and enterprise Shopify projects. The agency combines technical development, SEO, and digital strategy to deliver comprehensive eCommerce solutions.

For brands that need both a strong technical build and organic search performance from the same partner, Coalition sits in a fairly rare position. They have handled complex builds at scale and bring a data-informed approach to both development decisions and growth strategy.

Services: Enterprise Shopify development, SEO, PPC, CRO, Shopify Plus, custom integrations

5. BlueSwitch

Location: New York, NY | Best for: DTC and B2B Shopify Plus, conversion optimization, UX improvement

BlueSwitch specializes in conversion-focused Shopify website design and development. The agency works closely with US brands to optimize UX, improve customer journeys, and increase average order value.

BlueSwitch is a Shopify Plus agency specializing in developing high-performance eCommerce solutions for both direct-to-consumer (DTC) and business-to-business (B2B) brands. That dual B2C/B2B capability is not common. Most agencies pick one lane and stay there. BlueSwitch moving fluidly between both makes them useful for brands that sell across channels.

Services: Shopify Plus development, UX design, CRO, B2B and DTC builds

6. Sleepless Media

Location: Santa Cruz, CA | Best for: Lifestyle, outdoor, and food brands needing custom Shopify Plus builds

Sleepless Media is a US-based Shopify Plus agency with 20+ years of experience building high-converting Shopify stores. Frequently featured in Shopify's own Partner spotlight content, they bring deep eCommerce expertise to every project.

Their portfolio leans into lifestyle and national food brands, which means they understand how to balance visual storytelling with technical performance. They specialize in custom web design and branding, focusing on creating conversion-focused digital experiences for lifestyle, outdoor adventure, and national food brands.

Services: Custom Shopify Plus design and development, migrations, branding, ongoing optimization

7. Digital Silk

Location: New York, NY | Best for: Custom design-forward Shopify builds, enterprise brands wanting search-optimized storefronts

Digital Silk is a Shopify website development agency based in New York. They specialize in custom Shopify web design and development to create scalable eCommerce stores optimized for search engines and conversions.

Their strength is clean, intentional design work paired with technical execution. If your product requires a premium, polished storefront that also performs well in organic search, Digital Silk hits both.

Services: Custom Shopify design, development, SEO, branding

8. 1Digital Agency

Location: Philadelphia, PA | Best for: Mid-to-enterprise eCommerce brands, platform migrations, Shopify Plus

1Digital Agency is a Shopify website design agency based in Philadelphia. They specialize in eCommerce solutions to enhance online visibility and sales for brands across various industries.

They have a well-established practice around Shopify migrations, particularly from platforms like Magento. If you're pulling a brand off an aging platform and need someone who has done that exact thing dozens of times, 1Digital is experienced territory.

Services: Shopify Plus development, migrations, SEO, app integrations, eCommerce consulting

Choosing Between Them: A Framework That Actually Helps

It comes down to three filters.

Filter 1: Development depth vs. marketing integration. Some agencies are pure builders. Others wrap development inside a growth marketing practice. Know which you need before you talk to anyone. SmartSites and Coalition are strong on the marketing side. Lucent Innovation, BlueSwitch, and 1Digital go deeper on the development and integration side.

Filter 2: Enterprise vs. mid-market fit. While the top agencies represent the upper echelon of high-ticket enterprise development, mid-market brands often need highly experienced partners with more accessible entry points. Match the agency tier to your actual scope and budget. Bringing enterprise overhead to a $30K build just creates drag.

Filter 3: Long-term partner vs. one-time project. Successful Shopify partnerships should demonstrate continued value through ongoing optimization, strategic guidance, and adaptation to changing market conditions. If you want a team embedded in your roadmap, make sure the agency runs a retainer model that works for your velocity. Netalico and Lucent Innovation both operate well in this mode.

The Honest Reality of Agency Pricing in 2026

Some agencies charge $50 to $149 per hour depending on complexity. A high-quality agency doesn't stop at launch.

What that means practically: budget not just for the build, but for what comes after. Performance optimization, new feature development, app integrations, and ongoing A/B testing rarely fit inside a launch budget. The agencies that tell you this upfront, clearly and without pressure, are usually the ones worth working with long-term.

Final Take

Shopify in 2026 is not a simple platform anymore. The ecosystem runs deep, from headless commerce and custom checkout extensions to AI-powered personalization and complex B2B workflows. The agency you choose needs to match where your store is going, not just where it is today.

If you are a developer or a CTO evaluating partners for a serious Shopify project, start by scoping your real requirements before you request a single proposal. The agencies on this list are genuinely capable. The difference in outcomes usually comes from how well you match the engagement to the need.

For deeper technical breakdowns on Shopify architecture, eCommerce development patterns, and web infrastructure strategy, I write regularly at krunalkanojiya.com. If this was useful, that is a good next place to go.

How to Use the any Type and When to Avoid It

Krunal Kanojiya — Sun, 28 Jun 2026 10:57:27 +0000

TLDR

any is a special TypeScript type that turns off all type checking for a variable. It lets you assign any value and call any method without errors. This makes it feel helpful but it quietly breaks the safety TypeScript gives you. Avoid any in almost every case. Use unknown when you do not know the type yet. Only use any as a last resort when migrating old JavaScript code or working with untyped third-party libraries.

What is the `any` Type?

any is a type that tells TypeScript to stop checking a variable. Once you mark something as any, TypeScript lets you do anything with it.

You can assign a string. You can assign a number. You can call methods that do not exist. TypeScript will not say a word. It just trusts you to get it right.

let value: any = "hello";
value = 42;         // OK
value = true;       // OK
value = { x: 1 };  // OK
value = null;       // OK
value();            // OK — TypeScript does not check this
value.foo.bar.baz;  // OK — TypeScript does not check this either

All of those lines compile without error. But some of them will crash hard at runtime.

How `any` Disables Type Checking

The core problem with any is simple. TypeScript checks types to catch bugs. any turns that checking off. It is like buying a smoke detector and then removing the battery.

Here is what normally happens with a typed variable:

let name: string = "Alice";
name.toUpperCase(); // OK
name.push("Bob");   // Error: Property 'push' does not exist on type 'string'.

TypeScript catches the mistake. Now compare that with any:

let name: any = "Alice";
name.toUpperCase(); // OK at compile time
name.push("Bob");   // Also OK at compile time — but crashes at runtime

TypeScript sees any and stops checking. The bug gets through to production.

Two Ways `any` Appears in Your Code

Explicit `any`

This is when you write any yourself on purpose:

let data: any = fetchSomeData();
let input: any;
function process(value: any): any { ... }

You chose to use any. TypeScript respects that and skips type checking.

Implicit `any`

This is when TypeScript cannot figure out the type and defaults to any quietly:

// TypeScript cannot infer the type of 'item' here
function logItem(item) {
  console.log(item);
}

Without a type annotation, TypeScript gives item the type any if noImplicitAny is off. This is more dangerous because it is silent.

The noImplicitAny flag (included in strict: true) stops this from happening:

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

With the error in place, you are forced to add a proper type:

function logItem(item: string): void {
  console.log(item);
}

Why `any` is Dangerous

Problem 1: Errors reach runtime instead of compile time

function getFirstChar(value: any): string {
  return value[0]; // TypeScript is fine with this
}

getFirstChar(123);
// No compile error
// But at runtime: 1 (not a crash here, but wrong behavior)

getFirstChar(null);
// No compile error
// Crashes at runtime: Cannot read properties of null

Problem 2: `any` spreads to other variables

When you assign an any value to another variable, that variable also becomes any. This is called any infection. One any can quietly spread through your whole codebase.

let raw: any = getData();

let name = raw.name;       // name is now any
let age = raw.age;         // age is now any
let city = raw.address.city; // city is now any

// TypeScript checks none of these
age.toUpperCase();          // No error — but crashes at runtime if age is a number

Problem 3: You lose IDE support

TypeScript powers your editor's autocomplete, hover hints, and refactoring tools. When a variable is any, none of that works. You lose the benefits that make TypeScript worth using.

let user: any = getUser();
user. // No autocomplete suggestions here

Compare that with a typed variable:

let user: { name: string; age: number } = getUser();
user. // Editor shows: name, age

Problem 4: Bugs survive code reviews

Type errors show up in CI/CD pipelines and in your editor. They are hard to miss. But runtime crashes from any only show up when users hit that code path. They are much harder to catch.

The `any` Infection Example

Here is a realistic example of how any spreads:

// Step 1: One any at the boundary
const response: any = await fetch("/api/user").then(r => r.json());

// Step 2: Everything from it is also any
const userId = response.id;       // any
const userName = response.name;   // any
const userEmail = response.email; // any

// Step 3: Functions that use these values lose type safety too
function sendWelcomeEmail(email: any): void {
  // email is any, no checks inside this function either
}

// Step 4: The bug is invisible
sendWelcomeEmail(userId); // Wrong value passed — no error

None of these lines produce a TypeScript error. But the last line passes an ID where an email is expected. In production, users get a broken welcome email at best, or a crash at worst.

When is `any` Actually Okay to Use?

There are a small number of situations where any is an acceptable choice. Be honest with yourself about which category you are in before reaching for it.

Situation	Is `any` Okay?	Better Alternative
Migrating a JS file to TS step by step	Yes, temporarily	Add types file by file
Third-party library with no type definitions	Sometimes	Write a `.d.ts` file or use `unknown`
Truly unknown JSON data from an API	Temporarily	Use `unknown` + type guard
You do not want to figure out the type	No	Spend the time finding the right type
Prototype or throwaway script	Acceptable	Not needed for prod code
You are in a hurry	No	Technical debt that bites later

The Right Alternative: `unknown`

unknown is the safe version of any. You can assign anything to an unknown variable just like any. But TypeScript will not let you use the value until you check its type first.

let value: unknown = getData();

// This does not compile with unknown
value.toUpperCase();
// Error: 'value' is of type 'unknown'.

// You must check the type first
if (typeof value === "string") {
  value.toUpperCase(); // Now TypeScript knows it is a string — safe
}

Here is a side-by-side comparison:

	`any`	`unknown`
Can assign any value	Yes	Yes
TypeScript checks usage	No	Yes, after a type check
Autocomplete works	No	Yes, after narrowing
Crashes at runtime	Possible	Much less likely
Recommended	Almost never	When type is truly unknown

Practical example: Handling API responses safely

With any (unsafe):

async function getUser(): Promise<any> {
  const response = await fetch("/api/user");
  return response.json(); // Returns any
}

const user = await getUser();
console.log(user.name.toUpperCase()); // No error, but crashes if name is missing

With unknown (safe):

async function getUser(): Promise<unknown> {
  const response = await fetch("/api/user");
  return response.json();
}

const user = await getUser();

// Must check the shape before using it
if (
  typeof user === "object" &&
  user !== null &&
  "name" in user &&
  typeof (user as { name: unknown }).name === "string"
) {
  console.log((user as { name: string }).name.toUpperCase()); // Safe
}

Tip: For real projects, use a library like Zod to validate API responses instead of writing manual type guards. It is faster and more reliable.

How to Handle `any` When Migrating JavaScript Code

When you are moving a JavaScript project to TypeScript, you will see any everywhere. That is okay as a starting point. The goal is to replace it over time.

Use this step-by-step approach:

// Step 1: Start with any to get the file compiling
function processOrder(order: any): any {
  return order.total * 1.1;
}

// Step 2: Add a type for the input first
type Order = {
  id: number;
  total: number;
};

function processOrder(order: Order): any {
  return order.total * 1.1;
}

// Step 3: Add the return type
function processOrder(order: Order): number {
  return order.total * 1.1;
}

Go one function at a time. Do not try to fix everything at once.

How to Prevent `any` With ESLint

Setting noImplicitAny: true stops TypeScript from adding any silently. But it does not stop you from writing any yourself.

For that, use the @typescript-eslint/no-explicit-any rule:

// .eslintrc.json
{
  "rules": {
    "@typescript-eslint/no-explicit-any": "error"
  }
}

Now this will fail your lint check:

let data: any = fetch(); // ESLint error: Unexpected any. Specify a different type.

This is the best way to keep any out of a team codebase. The linter enforces it for everyone automatically.

`@ts-ignore` and `@ts-expect-error`: Related Escape Hatches

Two comment directives work like any but at the line level. They suppress TypeScript errors on the next line.

// @ts-ignore
const result = doSomethingBroken(); // TypeScript ignores errors on this line

// @ts-expect-error
const result2 = doSomethingBroken(); // Same, but gives an error if there is NO error

The difference between the two:

Directive	What it does
`// @ts-ignore`	Suppresses the error. No feedback if error disappears.
`// @ts-expect-error`	Suppresses the error. Gives a new error if the error is fixed.

Prefer @ts-expect-error over @ts-ignore. It will alert you when the suppression is no longer needed so you can clean it up.

Use both of these as rarely as possible. They hide real problems.

`any` vs `unknown` vs `never`: Quick Comparison

Type	What You Can Assign To It	What You Can Do With It
`any`	Anything	Anything — no checks
`unknown`	Anything	Nothing until you narrow the type
`never`	Nothing	Nothing — it is an impossible type

let a: any = "hello";
a.toUpperCase();  // OK — no checking

let b: unknown = "hello";
b.toUpperCase();  // Error — must narrow first
if (typeof b === "string") {
  b.toUpperCase(); // OK — narrowed to string
}

let c: never;
c = "hello"; // Error — nothing can be assigned to never

Common Mistakes with `any`

Mistake 1: Using any for JSON responses

// Bad
const data: any = await response.json();

// Better
const data: unknown = await response.json();
// Then validate the shape before using it

Mistake 2: Spreading any through utility functions

// Bad: input and return are both any, spreading infection
function transform(input: any): any {
  return input.value;
}

// Good: types are explicit
type InputData = { value: string };
function transform(input: InputData): string {
  return input.value;
}

Mistake 3: Casting to any to silence errors

// Bad: hiding a real type mismatch
const user = getUser() as any;
user.nonExistentMethod(); // Compiles, crashes at runtime

// Good: fix the actual type issue
const user: User = getUser();

Mistake 4: Using any[] for arrays

// Bad
const items: any[] = [1, "two", true];

// Better: use a union type
const items: (number | string | boolean)[] = [1, "two", true];

// Or, if all items are the same type
const scores: number[] = [1, 2, 3];

FAQ

Q: Is any the same as not using TypeScript at all?
Almost, yes. A variable typed as any gets zero type checking. Using any everywhere is the same as writing plain JavaScript with extra steps.

Q: When should I use any vs unknown?
Use unknown when you do not know the type yet but want TypeScript to keep checking how you use the value. Use any only as a last resort during migration or when a library gives you no other choice.

Q: Can I use any in a production codebase?
You can, but you should not. Every any is a place where type safety breaks down and bugs can hide. Use ESLint to ban it and replace it with proper types or unknown.

Q: Does noImplicitAny ban all any?
No. noImplicitAny only stops TypeScript from silently adding any when it cannot infer a type. It does not stop you from writing any yourself. Use the @typescript-eslint/no-explicit-any ESLint rule to ban explicit any too.

Q: What happens to any in the compiled JavaScript?
Nothing. Like all types, any is removed at compile time. It is only a TypeScript concept and has no effect on the JavaScript output.

Q: Is it okay to use any in test files?
It is more acceptable in test files than in production code. But you should still prefer proper types. Typed tests catch more bugs and are easier to maintain.

What You Learned

any turns off all type checking for a variable and lets you assign or do anything with it
TypeScript defaults to implicit any when it cannot infer a type. noImplicitAny: true stops this
any is dangerous because errors skip compile time and reach runtime instead
any spreads to other variables. One any can infect a whole chain of code
unknown is the safe alternative. You must check the type before using an unknown value
Use any only for JS migration or untyped third-party libraries, and replace it as soon as you can
Use @typescript-eslint/no-explicit-any to ban any from your team's codebase
Prefer @ts-expect-error over @ts-ignore when you must suppress a TypeScript error

Sources: TypeScript Handbook — Everyday Types | typescript-eslint — no-explicit-any | TypeScript TSConfig Reference

Pinecone vs Weaviate vs Milvus vs Qdrant: Which Vector DB in 2026?

Krunal Kanojiya — Sun, 28 Jun 2026 05:15:59 +0000

I have helped a number of teams pick a vector database in the last year. The conversation always starts the same way: four logos, one Slack message, one question — which one?

The honest answer is that all four are good. The useful answer is that each one is built for a different set of constraints. Getting this decision wrong does not break your application on day one. It shows up six months later when your bill is three times your compute budget, or your filtered search recall starts degrading under load.

This post gives you the architecture overview, latency benchmarks, filtering quality comparison, hybrid search comparison, real cost numbers, and code examples for each. The full 4,000-word breakdown with detailed cost formulas and every edge case is at krunalkanojiya.com.

The Short Answer First

Skip the full read if you already know your constraints:

Pinecone — Fully managed, zero infrastructure, best for datasets under 10M vectors
Qdrant — Best filtering, native hybrid search, lowest cost at scale, best default for most RAG pipelines in 2026
Weaviate — Built-in vectorization, multi-modal, most mature BM25 + dense hybrid search
Milvus — Only real option above 100M vectors, GPU-accelerated indexing, needs Kubernetes

For everything else, keep reading.

Architecture and Deployment at a Glance

How each database handles deployment defines most of the tradeoffs that follow.

Pinecone is a black box. You get an API key. No infrastructure decisions, no index tuning, no ops. The 2026 default is serverless: pay per read unit, write unit, and storage. No idle charges.

Weaviate uses HNSW indexing with a modular architecture that lets you swap vectorizers, rerankers, and embedding models without rebuilding your schema. In April 2026, v1.37 shipped a native MCP Server, making it the first vector database where LLMs and agents can query and write directly without custom integration code.

Milvus is the most architecturally complex. It separates compute from storage at the infrastructure level with specialized node types (query nodes, data nodes, index nodes) on Kubernetes. Milvus 2.6 replaced its Kafka/Pulsar dependency with Woodpecker, its own WAL system built on object storage.

Qdrant is written in Rust and runs as a single binary or Docker container. No Kubernetes required for most workloads. v1.14 (April 2026) shipped GPU-accelerated HNSW indexing (4x faster index builds on AWS) and Multi-AZ clusters with 99.95% uptime SLAs.

Deployment complexity, simplest to hardest:
Pinecone (no ops) → Qdrant (single binary) → Weaviate (Docker Compose) → Milvus (Kubernetes)

Performance Benchmarks

Benchmarks from Salt Technologies AI's Vector Database Performance Benchmark 2026, covering 1M vectors at 1536 dimensions:

Database	p50 Latency	p99 Latency	Notes
Qdrant (self-hosted)	4ms	8–12ms	Lowest latency of all purpose-built vector DBs
Milvus (with GPU)	6ms	12–18ms	CPU-only is 15–25ms
Pinecone Serverless	20–30ms	40–80ms (cold)	Warm queries 10–15ms
Weaviate Cloud	50–70ms	100–150ms	Self-hosted is significantly faster

A few things worth knowing about these numbers. Qdrant's 4ms p50 is consistent across warm and cold queries because it runs on infrastructure you control. Pinecone's cold query spike matters for applications with bursty or overnight-quiet traffic. Weaviate self-hosted with binary quantization reaches 20–40ms p99, much better than the managed numbers.

Filtering: The Most Underrated Difference

Filtering is the most important practical difference for production applications. Almost every real RAG query includes filters — user ID, date range, category, tenant ID.

The core problem: post-filtering retrieves candidates from the index first, then applies the filter. If only 1% of your vectors match the filter, the traversal wastes 99% of its work. Recall drops significantly under selective filters.

Qdrant applies the payload filter during HNSW graph traversal, not after. Recall stays high even when filters reduce the dataset to a tiny fraction of the total.

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue, Range

client = QdrantClient(url="http://localhost:6333")

results = client.query_points(
    collection_name="documents",
    query=query_vector,
    query_filter=Filter(
        must=[
            FieldCondition(key="user_id", match=MatchValue(value=42)),
            FieldCondition(key="category", match=MatchValue(value="technical")),
            FieldCondition(
                key="created_at",
                range=Range(gte=1700000000)
            ),
        ]
    ),
    limit=10,
)

Weaviate also applies filters during index traversal using an inverted index alongside the HNSW graph. Recall under selective filters is strong and comparable to Qdrant.

Milvus uses a scalar index built alongside the vector index. Handles complex filters well at billion-scale under high QPS through distributed query execution.

Pinecone handles metadata filtering well for common equality and range filters. Under highly selective filters on large datasets, recall can degrade. The filter syntax is also less expressive than the other three.

Filtering winner: Qdrant and Weaviate for correctness under selective filters. Milvus for filtering at billion-scale.

Hybrid Search

Hybrid search combines dense vectors with sparse BM25 to handle both semantic queries and exact keyword matches. It consistently outperforms pure semantic search for technical docs, product catalogs, and anything with specific identifiers like model numbers or proper nouns.

Weaviate has the most mature implementation. BM25 + dense vector search is processed in a single unified query, not two separate calls you merge in application code.

import weaviate
from weaviate.classes.query import HybridFusion

client = weaviate.connect_to_weaviate_cloud(
    cluster_url="YOUR_CLUSTER_URL",
    auth_credentials=weaviate.auth.AuthApiKey("YOUR_API_KEY"),
)

collection = client.collections.get("Documents")

results = collection.query.hybrid(
    query="vector database filtering performance",
    vector=query_embedding,
    fusion_type=HybridFusion.RELATIVE_SCORE,
    limit=10,
)

client.close()

Qdrant supports native sparse vectors alongside dense vectors in named vector collections. Query them together with Reciprocal Rank Fusion.

from qdrant_client import QdrantClient
from qdrant_client.models import SparseVector, Prefetch, FusionQuery, Fusion

client = QdrantClient(url="http://localhost:6333")

results = client.query_points(
    collection_name="documents",
    prefetch=[
        Prefetch(query=dense_vector, using="dense", limit=20),
        Prefetch(
            query=SparseVector(indices=sparse_indices, values=sparse_values),
            using="sparse",
            limit=20,
        ),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=10,
)

Milvus 2.6 ships BM25 full-text search built-in, benchmarked at 400% higher throughput than Elasticsearch on equivalent hardware. Teams can collapse a two-system stack (Elasticsearch + vector DB) into a single Milvus deployment.

Pinecone supports hybrid search through sparse-dense vectors. Clean implementation, less flexible than Qdrant's named vector design when combining more than two vector types.

Hybrid search winner: Weaviate for the most integrated implementation. Qdrant for flexibility. Milvus for teams replacing Elasticsearch.

Real Cost Numbers at 10M Vectors

This is where teams get surprised the most. The number on the pricing page is rarely the number you pay in production.

Database	10M vectors managed	10M vectors self-hosted	Best scenario
Pinecone Serverless	$70–$100/month	Not available	Low query volume, small scale
Weaviate Cloud	~$135/month (BQ enabled)	$80–$120/month	Hybrid search with no extra cost
Milvus (Zilliz)	$65–$120/month	$60–$100/month	Billion-scale with quantization
Qdrant Cloud	~$65/month	$20–$40/month	Best self-hosted economics

A few notes worth calling out.

Pinecone bills on read units, write units, and storage. At high query volume, read unit costs stack up fast. Weaviate's dimension-based billing multiplies by replication factor — enabling Binary Quantization is essential at any scale above 1M vectors or costs blow up. Milvus 2.6's RaBitQ 1-bit quantization compresses indexes to 1/32 their original size at 95% recall, which materially changes the hardware required at billion-scale. Self-hosted Qdrant on a $40/month VPS with binary quantization handles 10M vectors comfortably with sub-10ms p99.

Cost winner: Self-hosted Qdrant for lowest total cost at any scale. Pinecone Serverless for small workloads where zero-ops is worth the premium.

Quick Start Code for Each

Pinecone — fastest to get started, three lines to insert:

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="your-api-key")
pc.create_index(
    name="my-index",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1")
)
index = pc.Index("my-index")
index.upsert(vectors=[{"id": "doc-1", "values": embedding, "metadata": {"text": "..."}}])
results = index.query(vector=query_embedding, top_k=10, include_metadata=True)

Qdrant — clean defaults, sane out-of-the-box behavior:

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
client.upsert(
    collection_name="documents",
    points=[PointStruct(id=1, vector=embedding, payload={"content": "...", "user_id": 42})]
)
results = client.query_points(collection_name="documents", query=query_embedding, limit=10)

The Decision Matrix

Requirement	Pick
Zero infrastructure, fastest setup	Pinecone
Best filtering recall under selective filters	Qdrant
Native hybrid search out of the box	Weaviate
Built-in vectorization (no separate embedding call)	Weaviate
Dataset above 100M vectors	Milvus
GPU-accelerated index builds	Milvus or Qdrant Cloud
Lowest self-hosted cost	Qdrant
Replace Elasticsearch with vector search	Milvus
LLM agent integration via MCP	Weaviate
Most teams building RAG in 2026	Qdrant

Where to Go Deeper

This post covers the key differences. The full comparison at my blog goes deeper on Pinecone's Dedicated Read Nodes and BYOC setup, Weaviate's Diversity Search using MMR, Milvus's tiered hot/cold storage, Qdrant's audit logging, the full cost formulas for each pricing model, and the Lambda vs Kappa architecture question for teams running both batch and streaming ingestion alongside vector search.

Read the full guide here:
Pinecone vs Weaviate vs Milvus vs Qdrant (2026): Full Comparison

Which vector database are you currently using in production? And what made you pick it? Drop it in the comments.

Batch vs Real-Time Streaming: When to Use Each (with Examples)

Krunal Kanojiya — Fri, 26 Jun 2026 12:01:16 +0000

Every data pipeline makes one foundational decision before a single line of code is written.

Does it process data in scheduled chunks, or does it process data as events arrive?

That is the batch versus streaming decision. It looks simple on paper. In practice, it shapes everything: the tools you use, the infrastructure you maintain, the guarantees you can make about data freshness, and the cost you pay every month to keep it running.

Teams that build streaming pipelines when batch would have sufficed end up maintaining complex infrastructure for a problem that did not require it. Teams that build batch when their use case demands real-time discover the gap at the worst possible moment.

This post gives you a decision framework, a side-by-side comparison, and working code examples for both patterns. The full deep-dive with architecture diagrams, Lambda vs Kappa tradeoffs, and Databricks Real-Time Mode is at the original article on Lucent Innovation.

How Batch Works (and Where It Breaks Down)

Batch collects data over a window of time, then processes it all at once when a scheduled trigger fires.

Think of it like doing laundry. You do not wash one shirt the moment it gets dirty. You wait for a full load, then run the machine. Data accumulates throughout the day. At a scheduled time, the job picks up everything, transforms it, and loads the output.

Where batch wins:

Complex multi-table joins and heavy aggregations with no time pressure per record
ML model training on large, static datasets
Nightly financial reconciliation and compliance reporting
Historical data migrations and backfills

Where batch breaks down:

Use cases where decisions depend on data that is happening right now
A fraud detection system running on nightly batch is not a fraud system. It is a fraud reporting system.

Batch Pipeline Example (PySpark)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, sum, date_trunc

spark = SparkSession.builder.appName("NightlyRevenueRollup").getOrCreate()

# Read from Delta Lake Bronze table
raw_orders = spark.read.format("delta").load("/mnt/bronze/orders")

# Transform: aggregate daily revenue per product
daily_revenue = (
    raw_orders
    .filter(col("status") == "completed")
    .withColumn("order_date", date_trunc("day", col("created_at")))
    .groupBy("order_date", "product_id")
    .agg(sum("amount").alias("total_revenue"))
)

# Write to Delta Lake Gold table
(
    daily_revenue.write
    .format("delta")
    .mode("overwrite")
    .option("replaceWhere", "order_date = current_date()")
    .save("/mnt/gold/daily_revenue")
)

This job runs on a schedule (nightly, hourly, whatever the SLA allows). It reads a full time window, transforms it, and overwrites the output partition. Simple failure mode: if it breaks, you fix the logic and rerun the window.

How Streaming Works (and Where It Costs You)

Streaming treats data as a continuous flow of individual events. Each event is processed the moment it arrives, without waiting for others to accumulate.

Think of it like a moving walkway at an airport. Nobody waits for 500 people to gather before the walkway starts. It runs continuously. Each person moves forward the moment they step on.

A streaming pipeline runs 24 hours a day, 7 days a week, processing each event within milliseconds to seconds of arrival.

Where streaming wins:

Fraud detection before a transaction clears
Real-time personalization based on current browsing behavior
Operational dashboards that need second-level granularity
IoT and sensor telemetry for predictive maintenance

Where streaming costs you:

Always-on compute, persistent state storage, and continuous monitoring
State management across windowed aggregations grows with data volume
Schema changes from source systems can corrupt output silently while the pipeline keeps running
A simple batch ELT pipeline costs $15,000–$50,000 to build. A production streaming pipeline with proper monitoring: $50,000–$200,000+

Streaming Pipeline Example (Spark Structured Streaming)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, window, sum
from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType

spark = SparkSession.builder.appName("FraudSignalStream").getOrCreate()

# Define schema for incoming payment events
payment_schema = (
    StructType()
    .add("transaction_id", StringType())
    .add("user_id", StringType())
    .add("amount", DoubleType())
    .add("merchant_id", StringType())
    .add("event_time", TimestampType())
)

# Read from Kafka topic
raw_stream = (
    spark.readStream
    .format("kafka")
    .option("kafka.bootstrap.servers", "kafka-broker:9092")
    .option("subscribe", "payment_events")
    .option("startingOffsets", "latest")
    .load()
    .select(from_json(col("value").cast("string"), payment_schema).alias("data"))
    .select("data.*")
)

# Compute 5-minute rolling spend per user for anomaly detection
windowed_spend = (
    raw_stream
    .withWatermark("event_time", "10 minutes")
    .groupBy(
        col("user_id"),
        window(col("event_time"), "5 minutes")
    )
    .agg(sum("amount").alias("total_spend_5min"))
)

# Write results to Delta Lake for downstream fraud scoring
(
    windowed_spend.writeStream
    .format("delta")
    .outputMode("append")
    .option("checkpointLocation", "/mnt/checkpoints/fraud_signal")
    .start("/mnt/silver/fraud_signals")
)

This pipeline runs continuously. The checkpointLocation ensures exactly-once processing if the job restarts. The watermark handles late-arriving events. The windowed aggregation maintains rolling state in memory.

The Decision Framework: One Question Answers It

What happens if the data is one hour old?

If the answer is nothing meaningful, batch is the right choice.

If the answer is a real business loss, streaming earns its complexity.

Four follow-up questions to confirm:

Question	If Yes	If No
Does stale data cause a direct business loss?	Streaming	Batch
Does the output trigger a real-time action?	Streaming	Batch
Does your team have streaming ops experience?	Streaming feasible	Stick to batch
Would hourly refreshes satisfy the requirement?	Micro-batch	Streaming

Micro-Batch: The Middle Ground Most Teams Overlook

Between batch and streaming sits micro-batch. It is the pattern Spark Structured Streaming uses by default and the one that solves most "near real-time" requirements without full streaming complexity.

Micro-batch runs the same pipeline logic as streaming but on a short fixed interval: every 30 seconds, every minute, every 5 minutes.

Most stakeholders who say they want "real-time" data would be fully satisfied with a dashboard that refreshes every minute. That is micro-batch, not streaming, and it costs a fraction of the infrastructure.

Latency requirement   →   Pattern
─────────────────────────────────────────────
Hours                 →   Batch (scheduled)
Minutes               →   Micro-batch (short trigger)
Sub-minute + action   →   Streaming (Structured Streaming)
Sub-second + action   →   Real-Time Mode (Databricks RTM)

Micro-Batch in Practice

# Micro-batch: trigger every 60 seconds instead of continuously
(
    windowed_spend.writeStream
    .format("delta")
    .outputMode("append")
    .trigger(processingTime="60 seconds")   # <-- this is the only change
    .option("checkpointLocation", "/mnt/checkpoints/fraud_signal")
    .start("/mnt/silver/fraud_signals")
)

One line change. 60-second freshness. Dramatically simpler operational model.

Both Patterns in One Place: Databricks Lakeflow

On Databricks, batch and streaming live in the same pipeline definition using Lakeflow Spark Declarative Pipelines. No separate tools. No second codebase.

import dlt
from pyspark.sql.functions import col, sum, window

# STREAMING TABLE: processes each event as it arrives
@dlt.table(
    name="silver_payment_events",
    comment="Cleaned payment events, streamed from Kafka"
)
def silver_payment_events():
    return (
        spark.readStream
        .format("kafka")
        .option("kafka.bootstrap.servers", "kafka-broker:9092")
        .option("subscribe", "payment_events")
        .load()
    )

# MATERIALIZED VIEW: runs as batch, re-computes on a schedule
@dlt.table(
    name="gold_daily_revenue",
    comment="Daily revenue rollup, refreshed hourly"
)
def gold_daily_revenue():
    return (
        dlt.read("silver_payment_events")
        .groupBy("merchant_id", "order_date")
        .agg(sum("amount").alias("total_revenue"))
    )

The streaming table (silver_payment_events) processes events continuously. The materialized view (gold_daily_revenue) refreshes on a trigger or schedule. Both are governed by Unity Catalog. Both write to Delta Lake. One pipeline definition, two patterns, zero context switching.

Real-World Pattern Map

Use Case	Pattern	Why
Nightly revenue reporting	Batch	Hourly freshness acceptable
ML model training	Batch	Full static dataset required
Historical data migration	Batch	No real-time constraint
Fraud detection	Streaming	Decision before transaction clears
Live inventory dashboard	Streaming	Stockout response requires current state
IoT anomaly detection	Streaming	Equipment failure cannot wait
Stakeholder dashboard "refreshed often"	Micro-batch	Minutes of freshness, batch cost
Compliance reporting	Batch	Fixed time window, no urgency

The Full Picture

This post covers the decision framework and working code examples for both patterns. The full article at Lucent Innovation goes deeper on:

Lambda Architecture vs Kappa Architecture for systems that need both patterns simultaneously
Databricks Real-Time Mode (GA March 2026) and how it achieves single-digit millisecond P99 latency without switching to Flink
The three hidden streaming costs teams consistently underestimate: state management, exactly-once delivery, and silent schema drift
How ELT handles streaming more naturally than ETL due to the pre-transformation bottleneck

Read the full guide here:
Batch vs Streaming Pipelines: How to Choose in 2026

Which pattern are you currently running in production? Drop it in the comments.

Your Data Engineering Learning Path: 2026 Edition

Krunal Kanojiya — Thu, 25 Jun 2026 10:10:31 +0000

Data engineering in 2026 is not what it was three years ago.

The job has expanded. Modern data engineers design lakehouse architectures, run streaming and batch pipelines on the same platform, enforce data quality at ingestion time, and track cloud costs per pipeline run. The tooling has converged around a smaller number of platforms that do much more.

If you are learning data engineering now, or leveling up from an older stack, the volume of things to learn can feel paralyzing. This checklist breaks it into a clear sequence so you know exactly what to learn, in what order, and why each piece matters.

The full deep-dive guide behind this checklist lives at Modern Data Engineering: The Complete Guide. This post gives you the skeleton. The full guide gives you the muscle.

Stage 1: Get the Fundamentals Right

Before picking tools, understand the concepts. These are the building blocks every data engineer needs regardless of platform.

What to learn:

[ ] What a data pipeline actually is — how data moves from source to destination, what stages it passes through, and what makes a pipeline fragile vs reliable. Understand push vs pull patterns and what fan-in/fan-out means in practice.
[ ] ETL vs ELT — extract, transform, load vs extract, load, transform. The difference is where transformation happens. In cloud-native platforms like Databricks, ELT is the default because the destination has enough compute to transform at scale. Know when each pattern applies.
[ ] Batch vs streaming — batch processes large chunks of data on a schedule; streaming processes records as they arrive. Most production systems use both. Understand the latency, cost, and complexity tradeoffs before choosing.

The real-time analytics market is projected to grow from $14.5 billion in 2023 to over $35 billion by 2032. Streaming is no longer optional knowledge.

You are ready for Stage 2 when: You can explain what a pipeline is, why ETL is being replaced by ELT in cloud environments, and when you would use batch vs streaming.

Stage 2: Understand Modern Data Storage

Where you put data matters as much as how you move it. The storage landscape has shifted significantly.

What to learn:

[ ] Data warehouse vs data lake vs lakehouse — warehouses are fast and reliable but expensive and rigid. Data lakes are cheap and flexible but turn into unmanaged swamps without governance. The lakehouse model combines both. Know the tradeoffs and why the lakehouse has become the default architecture for new builds.
[ ] Lakehouse architecture — a lakehouse stores all data (structured and unstructured) in open-format cloud storage, then adds a reliability layer that provides ACID transactions, schema enforcement, and fast queries. One platform for data engineering, analytics, and AI.
[ ] Delta Lake — the open-source storage layer that makes the lakehouse work. Adds ACID transactions, time travel, schema enforcement, and Change Data Feed to files in S3, ADLS, or GCS. If you are working with Databricks, this is non-negotiable.

The four things Delta Lake gives you that plain files do not:

Capability	Why It Matters
ACID transactions	Writes fully complete or fully roll back. No partial corruption.
Schema enforcement	Bad data is rejected at write time, before it lands.
Time travel	Query any previous table version for debugging, audits, or rollbacks.
Change Data Feed	Track row-level inserts, updates, deletes without full table scans.

You are ready for Stage 3 when: You can explain why a plain S3 data lake is unreliable for production use, and what Delta Lake adds to fix it.

Stage 3: Learn the Databricks Platform

Databricks is the dominant platform for building modern data pipelines and lakehouses. Founded by the creators of Apache Spark, Delta Lake, and MLflow, it has become the standard for teams running large-scale data work.

What to learn:

[ ] What Databricks is and how it is structured — a unified workspace for SQL, Python, notebooks, and pipelines. Serverless compute that scales automatically. Native support for both batch and streaming.
[ ] The Databricks tool stack for 2026:

Layer	Tool	What It Does
Ingestion	Lakeflow Connect	Pull data from sources into Bronze layer
Storage	Delta Lake	Store data reliably with ACID guarantees
Transformation	Lakeflow Declarative Pipelines	Clean and model data through Bronze, Silver, Gold
Orchestration	Lakeflow Jobs	Schedule and coordinate pipeline runs
Governance	Unity Catalog	Access control, lineage tracking, auditing
Analytics	Databricks SQL	SQL queries and dashboards on governed data

[ ] Unity Catalog — in 2026, Unity Catalog is not optional on Databricks. It is the foundation for access control, data lineage, auditing, and discovery. If you skip it, you are building without governance.

You are ready for Stage 4 when: You can navigate a Databricks workspace, understand how Lakeflow and Unity Catalog connect, and explain what happens to data as it moves from ingestion to analytics.

Stage 4: Build Production-Grade Pipelines

Knowing the tools is not the same as using them reliably in production. This stage is where you go from "I can write a Spark job" to "I build pipelines that do not break."

What to learn:

[ ] Medallion Architecture (Bronze, Silver, Gold) — the standard pattern for organizing data inside a lakehouse. Bronze is raw data as-arrived. Silver is cleaned and validated. Gold is aggregated and business-ready. Schema enforcement lives at the Bronze-to-Silver boundary.
[ ] Incremental loads and CDC — most pipelines should not reprocess all data on every run. Learn how to build pipelines that process only what changed since the last run. Change Data Capture (CDC) tracks row-level changes so downstream tables update incrementally instead of via full scans.
[ ] Data quality and observability — Gartner forecasts that 50% of organizations with distributed data architectures will adopt observability platforms in 2026, up from under 20% in 2024. Quality checks and pipeline monitoring are now baseline requirements, not advanced features.
[ ] OPTIMIZE, VACUUM, and Liquid Clustering — Delta tables accumulate small files over time. OPTIMIZE compacts them. VACUUM removes stale files after your retention window. Liquid Clustering replaces manual partitioning for new tables. Know how and when to run each.

You are ready for Stage 5 when: You can build a pipeline that runs incrementally, enforces schema at each layer, handles errors without corrupting data, and stays performant over time.

Stage 5: Understand Where the Industry Is Heading

Data engineering in 2026 has new pressures that did not exist two years ago. These are not optional topics — they are becoming normal parts of the role.

What to follow:

[ ] AI-augmented data operations — AI tools are now involved in pipeline monitoring, anomaly detection, debugging, and performance tuning, not just during development. The global autonomous data platform market is projected to grow from $2.51 billion in 2025 to $15.23 billion by 2033.
[ ] FinOps for data — data engineering workloads are expensive. Tracking cost per pipeline run, right-sizing compute, and justifying cloud spend are now expected skills. If you are building on Databricks, learn auto-scaling and SQL warehouse sizing from the start.
[ ] Unified batch and streaming — the debate between batch and streaming architectures is largely over. Winning platforms run both seamlessly, with shared governance, schema evolution, and auditability. The question is how to run both reliably on the same platform.
[ ] Platform engineering model — teams that treat data infrastructure as a product (standardized ingestion templates, reusable transformation patterns, centralized deployment) see 20% to 25% lower operational overhead compared to teams that build bespoke pipelines per project.

The Full Checklist at a Glance

STAGE 1: Fundamentals
  [ ] Data pipeline anatomy
  [ ] ETL vs ELT
  [ ] Batch vs streaming

STAGE 2: Storage
  [ ] Warehouse vs lake vs lakehouse
  [ ] Lakehouse architecture
  [ ] Delta Lake (ACID, time travel, CDF)

STAGE 3: Databricks Platform
  [ ] Databricks overview and workspace
  [ ] Lakeflow (Connect, Pipelines, Jobs)
  [ ] Unity Catalog

STAGE 4: Production Skills
  [ ] Medallion Architecture
  [ ] Incremental loads and CDC
  [ ] Data quality and observability
  [ ] OPTIMIZE, VACUUM, Liquid Clustering

STAGE 5: Industry Direction
  [ ] AI-augmented operations
  [ ] FinOps for data
  [ ] Unified batch + streaming
  [ ] Platform engineering model

Where to Go Deep

This checklist is the map. The full guide at Lucent Innovation covers every stage in detail, with technical explanations, real examples, tool comparisons, and links to deeper articles for each topic area.

Read the full Modern Data Engineering Guide here:
https://www.lucentinnovation.com/resources/it-insights/modern-data-engineering-guide

The guide is organized as a complete content series. You can start with the foundational concepts and follow the links through to the implementation and best practices articles, or jump directly to the section most relevant to where you are right now.

What stage are you currently at? Drop it in the comments.

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.

DEV Community: Krunal Kanojiya

Top Shopify Agencies in the US for 2026 (A Developer's Honest Take)

Why Picking a Shopify Agency Feels Harder Than It Should

What to Look for Before You Even Open a Proposal

Top Shopify Agencies in the US for 2026

1. Lucent Innovation

2. SmartSites

3. Lounge Lizard

4. Coalition Technologies

5. BlueSwitch

6. Sleepless Media

7. Digital Silk

8. 1Digital Agency

Choosing Between Them: A Framework That Actually Helps

The Honest Reality of Agency Pricing in 2026

Final Take

How to Use the any Type and When to Avoid It

TLDR

What is the any Type?

How any Disables Type Checking

Two Ways any Appears in Your Code

Explicit any

Implicit any

Why any is Dangerous

Problem 1: Errors reach runtime instead of compile time

Problem 2: any spreads to other variables

Problem 3: You lose IDE support

Problem 4: Bugs survive code reviews

The any Infection Example

When is any Actually Okay to Use?

The Right Alternative: unknown

Practical example: Handling API responses safely

How to Handle any When Migrating JavaScript Code

How to Prevent any With ESLint

@ts-ignore and @ts-expect-error: Related Escape Hatches

any vs unknown vs never: Quick Comparison

Common Mistakes with any

FAQ

What You Learned

Pinecone vs Weaviate vs Milvus vs Qdrant: Which Vector DB in 2026?

The Short Answer First

Architecture and Deployment at a Glance

Performance Benchmarks

Filtering: The Most Underrated Difference

Hybrid Search

Real Cost Numbers at 10M Vectors

Quick Start Code for Each

The Decision Matrix

Where to Go Deeper

Batch vs Real-Time Streaming: When to Use Each (with Examples)

How Batch Works (and Where It Breaks Down)

Batch Pipeline Example (PySpark)

How Streaming Works (and Where It Costs You)

Streaming Pipeline Example (Spark Structured Streaming)

The Decision Framework: One Question Answers It

Micro-Batch: The Middle Ground Most Teams Overlook

Micro-Batch in Practice

Both Patterns in One Place: Databricks Lakeflow

Real-World Pattern Map

The Full Picture

Your Data Engineering Learning Path: 2026 Edition

Stage 1: Get the Fundamentals Right

Stage 2: Understand Modern Data Storage

Stage 3: Learn the Databricks Platform

Stage 4: Build Production-Grade Pipelines

Stage 5: Understand Where the Industry Is Heading

The Full Checklist at a Glance

Where to Go Deep

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

What is the `any` Type?

How `any` Disables Type Checking

Two Ways `any` Appears in Your Code

Explicit `any`

Implicit `any`

Why `any` is Dangerous

Problem 2: `any` spreads to other variables

The `any` Infection Example

When is `any` Actually Okay to Use?

The Right Alternative: `unknown`

How to Handle `any` When Migrating JavaScript Code

How to Prevent `any` With ESLint

`@ts-ignore` and `@ts-expect-error`: Related Escape Hatches

`any` vs `unknown` vs `never`: Quick Comparison

Common Mistakes with `any`

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`