DEV Community: Rocky Chowdhury

Stop using any. Use unknown instead

Rocky Chowdhury — Mon, 11 May 2026 15:45:42 +0000

TypeScript's main job is to catch type bugs at compile time, before your code ever runs. But there are two types designed for the "I don't know the type yet" situation — any and unknown — and they behave very differently. One opts you out of the type system entirely. The other keeps you safe.

The problem with `any`

When you annotate something as any, you're telling TypeScript: "Trust me, I know what I'm doing — stop checking." TypeScript steps aside and lets you do whatever you want with that value, with zero verification.

function parseInput(input: any) {
  return input.toUpperCase();
}

parseInput(21); // No compile error — but crashes at runtime
// TypeError: input.toUpperCase is not a function

TypeScript doesn't check that 21 is a number, not a string. It happily compiles the code. The crash happens at runtime — silently defeating the entire purpose of using TypeScript in the first place.

any doesn't mean "flexible." It means "no type safety here." Every any is a hole in the type system through which bugs can silently enter.

The safer alternative: `unknown`

unknown is TypeScript's way of saying: "This value could be anything — and you must prove what it is before you use it." You cannot call methods or access properties on an unknown value without first narrowing its type.

function parseInput(input: unknown) {
  return input.toUpperCase();
  // Error: Object is of type 'unknown'
  // TypeScript catches this at compile time
}

With unknown, the bug is caught before it ever reaches production. TypeScript forces you to narrow the type before doing anything with the value.

Type narrowing

Type narrowing is the mechanism TypeScript uses to refine an unknown or union type down to something specific. You perform a runtime check — a type guard — and TypeScript adjusts the inferred type within each branch of that check. The most common tools are typeof, instanceof, and custom type guard functions.

Using `typeof`

function formatValue(value: unknown): string {
  if (typeof value === "string") {
    return value.toUpperCase(); // TypeScript knows it's a string here
  }
  if (typeof value === "number") {
    return value.toFixed(2);   // TypeScript knows it's a number here
  }
  return "Unsupported type";
}

Each if block narrows the type. Outside those blocks, value is still unknown. Inside them, TypeScript knows exactly what it is and unlocks the appropriate methods.

Using `instanceof`

instanceof is useful when working with class instances — most commonly when handling errors, which are typed as unknown in modern TypeScript.

function handleError(error: unknown): string {
  if (error instanceof Error) {
    return error.message; // Safe — TypeScript knows it's an Error object
  }
  return "Something went wrong";
}

Without the instanceof check, accessing error.message would be a compile error. The check is the proof TypeScript needs.

Custom type guards

For complex objects, you can write a custom type guard function using the value is Type return syntax:

interface ApiResponse {
  status: number;
  data:   string;
}

function isApiResponse(value: unknown): value is ApiResponse {
  return (
    typeof value === "object" &&
    value !== null &&
    "status" in value &&
    "data" in value
  );
}

function handleResponse(value: unknown) {
  if (isApiResponse(value)) {
    console.log(value.status); // TypeScript knows the full shape here
  }
}

Whenever you reach for any, ask yourself: is this actually "I don't know the type" or is it "I don't want to deal with the type right now"? The first case calls for unknown with narrowing. The second is technical debt. unknown keeps the compiler working for you — any sends it home early.

Keeping TypeScript DRY with Pick and Omit

Rocky Chowdhury — Mon, 11 May 2026 15:34:41 +0000

In a real-world codebase, interfaces grow. A User type might have 20+ properties covering everything from authentication to UI preferences. But not every part of the codebase needs all of them — a login form cares only about email and password, while an admin panel might need everything except password.

Without the right tools, you end up duplicating type definitions across files. That duplication is a quiet bug incubator. TypeScript's Pick and Omit utility types solve this by letting you derive focused, specialized types directly from a master interface — define each property exactly once and never repeat yourself.

The Problem: Manual Type Duplication

Start with a master User interface:

interface User {
  id:        number;
  name:      string;
  email:     string;
  password:  string;
  role:      "admin" | "user";
  createdAt: Date;
}

Without utility types, a developer might write separate interfaces for different contexts:

// For the login form
interface LoginCredentials {
  email:    string;
  password: string;
}

// For the public profile
interface PublicProfile {
  id:   number;
  name: string;
  role: "admin" | "user";
}

Now there are three places to update whenever the User schema changes. If email gets renamed to emailAddress, you have to remember to update LoginCredentials too. This is exactly the kind of maintenance burden DRY exists to eliminate.

`Pick<T, K>` — Select Only What You Need

Pick<T, K> creates a new type by selecting a subset of keys K from type T. You name the properties you want, and TypeScript builds the type from the master interface.

type LoginCredentials = Pick<User, "email" | "password">;
// Equivalent to: { email: string; password: string }

type PublicProfile = Pick<User, "id" | "name" | "role">;
// Equivalent to: { id: number; name: string; role: "admin" | "user" }

Both LoginCredentials and PublicProfile are now derived from the master User interface. Rename email to emailAddress in User and TypeScript immediately flags every derived type that referenced the old key — no manual search required.

Use Pick when you need a small, specific subset of a larger type — especially for form inputs, API request payloads, or narrow component props.

`Omit<T, K>` — Exclude What You Don't Want

Omit<T, K> creates a type with everything from T except the keys listed in K. It's more convenient than Pick when you want most of the properties and only need to drop a few.

type SafeUser = Omit<User, "password">;
// Equivalent to:
// { id: number; name: string; email: string; role: "admin" | "user"; createdAt: Date }

This pattern is common when returning user data from an API — you want the full object minus any sensitive fields.

A practical example

function getUser(id: number): Omit<User, "password" | "createdAt"> {
  // returns everything except the sensitive fields
}

Use Omit when your derived type needs most of the parent. It's less verbose than listing every key you do want with Pick.

`Pick` vs `Omit` — When to Use Which

A quick rule of thumb: if you need fewer than half the properties, reach for Pick. If you only need to exclude one or two, reach for Omit. Both produce the same kind of derived type — the choice is about readability and how many keys you're working with.

Scenario	Preferred utility
Need 2–3 specific fields from a large interface	`Pick`
Need everything except 1–2 sensitive fields	`Omit`
Defining a form input type	`Pick`
Stripping a field before an API response	`Omit`

Conclusion

Pick and Omit are not just convenience shortcuts — they're tools for maintaining a single source of truth for your data shapes. By deriving specialized types from a master interface instead of rewriting them, you eliminate redundancy and let TypeScript enforce consistency automatically. This is DRY applied at the type level, and it becomes increasingly valuable as your interfaces grow and your codebase scales.

DEV Community: Rocky Chowdhury

Stop using any. Use unknown instead

The problem with any

The safer alternative: unknown