{"article":{"slug":"your-type-guard-can-silently-drift-from-your-typescript-type","title":"Your Type Guard Can Silently Drift from Your TypeScript Type","subtitle":null,"summary":"TypeScript type guards can quietly diverge from the type they claim to checkβ€”rejecting valid data loudly or accepting invalid data silently. Why drift happens and how to keep guards in sync.","content_type":"tutorial","language":"en","canonical_url":"https://dev.to/nyaomaru/your-type-guard-can-silently-drift-from-your-typescript-type-o57","author":{"name":"nyaomaru","url":"https://dev.to/nyaomaru","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"DEV Community","url":"https://dev.to/","listing_slug":null,"listing":null},"topics":[{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Web Development","slug":"web-development","url":"https://listedarticles.com/topics/web-development"},{"name":"Developer Tools","slug":"developer-tools","url":"https://listedarticles.com/topics/developer-tools"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1512,"reading_minutes":7,"published_at":"2026-09-24T00:00:00.000Z","added_at":"2026-09-25T09:16:56.511Z","updated_at":"2026-09-25T09:16:56.511Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/your-type-guard-can-silently-drift-from-your-typescript-type","markdown_url":"https://listedarticles.com/articles/your-type-guard-can-silently-drift-from-your-typescript-type.md","example":false,"citation":"nyaomaru, DEV Community. \"Your Type Guard Can Silently Drift from Your TypeScript Type.\" 24 Sept 2026. https://dev.to/nyaomaru/your-type-guard-can-silently-drift-from-your-typescript-type-o57 (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://dev.to/nyaomaru/your-type-guard-can-silently-drift-from-your-typescript-type-o57"},"body_markdown":"# Your Type Guard Can Silently Drift from Your TypeScript Type\n\nHoi hoi! πŸ‘‹\n\nI'm @nyaomaru, a frontend engineer just back from a short vacation on Texel, a small island in the Netherlands. 😸🏝️\n\nToday, let's talk about a type guard that looks completely safe.\n\n\n```\nconst isUser = (value: unknown): value is User => {\n // runtime checks...\n};\n```\nLooks good, right?\n\nTypeScript knows that when `isUser(value)` returns `true`, the value is a `User`.\n\nBut there's a small problem\n\nTypeScript trusts that promise.\n\n\nIt doesn't prove that your runtime checks actually validate every field in `User`.\n\nAnd that's where type guards can slowly drift away from the types they claim to protect.\n\nLet's take a look! πŸ‘€\n\n## πŸ•³οΈ A Type Guard Can Become Outdated Without an Error\n\nImagine we start with this type\n\n\n```\ntype User = {\n id: string;\n name: string;\n};\n```\nAnd a hand-written type guard\n\n\n```\nconst isUser = (value: unknown): value is User => {\n if (typeof value !== \"object\" || value === null) {\n return false;\n }\n const candidate = value as Record;\n return typeof candidate.id === \"string\" && typeof candidate.name === \"string\";\n};\n```\nSo far, everything matches.\n\nLater, we update `User`\n\n\n```\ntype User = {\n id: string;\n name: string;\n role: \"admin\" | \"member\";\n};\n```\nBut we forget to update the guard.\n\n\n```\nconst isUser = (value: unknown): value is User => {\n if (typeof value !== \"object\" || value === null) {\n return false;\n }\n const candidate = value as Record;\n return typeof candidate.id === \"string\" && typeof candidate.name === \"string\";\n};\n```\nThere is no `role` check.\n\nBut this still compiles. 😿\n\n## 🧠 Why Doesn't TypeScript Catch This?\n\nBecause this\n\n\n```\n(value: unknown): value is User\n```\nis a user-defined type predicate.\n\nYou are telling TypeScript\n\nTrust me. If this function returns `true`, the value is a `User`.\n\n\nTypeScript can check whether the declared predicate type itself makes sense.\n\nBut it cannot generally prove that arbitrary runtime logic actually validates every part of that type.\n\nSo this is possible\n\n\n```\nconst isUser = (_value: unknown): _value is User => true;\n```\nTerrible guard.\n\nPerfectly valid TypeScript. 😹\n\nThe return type is a contract written by us, not a proof generated from the function body.\n\n## πŸ”„ This Becomes a Maintenance Problem\n\nThe annoying part isn't writing the guard once.\n\nIt's keeping these two things synchronized over time\n\n\n```\nTypeScript type\n ↕\nRuntime validation\n```\nTypes change.\n\nProperties get\n\n- added\n- removed\n- renamed\n- made optional\n- changed to another type\n\nAnd every time that happens, we need to remember that some runtime guard somewhere may also need an update.\n\nIf we forget, the compiler may not tell us.\n\nThat's the kind of bug I really don't want to rely on memory to prevent.\n\n## βœ… What If the Type Could Be the Contract?\n\nThis is one of the reasons I added `typedStruct` to `is-kit`.\n\nSuppose the application type already exists:\n\n\n```\ntype User = {\n id: string;\n name: string;\n age?: number;\n};\n```\nWe can build the guard against that existing type\n\n\n```\nimport { isNumber, isString, optionalKey, typedStruct } from \"is-kit\";\nconst isUser = typedStruct()({\n id: isString,\n name: isString,\n age: optionalKey(isNumber),\n});\n```\nNow the field map has a type-level relationship with `User`.\n\nAt runtime, it still performs ordinary object validation.\n\nBut at compile time, TypeScript can check whether the guards we declared match the object type they're supposed to follow.\n\n## πŸ’₯ Now Drift Becomes Visible\n\nLet's add a field again\n\n\n```\ntype User = {\n id: string;\n name: string;\n role: \"admin\" | \"member\";\n age?: number;\n};\n```\nBut forget to update the guard\n\n\n```\ntypedStruct()({\n id: isString,\n name: isString,\n age: optionalKey(isNumber),\n // TypeScript error:\n // role is missing\n});\n```\nNice.\n\nThe runtime bug became a compile-time problem.\n\nThe same thing happens if the guard uses an incompatible field type\n\n\n```\nimport {\n isNumber,\n isString,\n oneOfValues,\n optionalKey,\n typedStruct,\n} from \"is-kit\";\ntypedStruct()({\n id: isString,\n name: isNumber,\n // TypeScript error:\n // User[\"name\"] is string\n role: oneOfValues(\"admin\", \"member\"),\n age: optionalKey(isNumber),\n});\n```\nThis is the part I care about most.\n\n`typedStruct` doesn't eliminate maintenance.\n\nIt makes forgotten maintenance visible.\n\n## 🧩 Optional and Nullable Are Different\n\nAnother place where object guards can get confusing is optional properties.\n\nConsider:\n\n\n```\ntype User = {\n id: string;\n nickname?: string | null;\n};\n```\nThere are two separate ideas here\n\n\n```\nnickname may be absent\n```\nand\n\n\n```\nnickname may exist with the value null\n```\nThose are different runtime contracts.\n\nWith `typedStruct`\n\n\n```\nimport { isString, nullable, optionalKey, typedStruct } from \"is-kit\";\nconst isUser = typedStruct()({\n id: isString,\n nickname: optionalKey(nullable(isString)),\n});\n```\nNow\n\n\n```\nisUser({ id: \"user-1\" });\n// true\nisUser({\n id: \"user-1\",\n nickname: null,\n});\n// true\nisUser({\n id: \"user-1\",\n nickname: \"Neko\",\n});\n// true\nisUser({\n id: \"user-1\",\n nickname: 42,\n});\n// false\n```\nI like keeping these two decisions explicit:\n\n- \n`optionalKey(...)` β†’ the property may be absent\n- \n`nullable(...)` β†’ the value may be`null`\n\nThey look similar at first, but they describe different things.\n\n## 🌳 Nested Types Don't Need to Be Duplicated Either\n\nNow imagine a larger type:\n\n\n```\ntype Account = {\n readonly id: string;\n readonly profile: {\n readonly displayName: string;\n readonly bio: string | null;\n } | null;\n readonly tags: readonly string[];\n};\n```\nWe could manually copy the profile shape into another type.\n\nBut that creates another thing that can drift.\n\nInstead, we can reference the type we already have\n\n\n```\nimport { arrayOf, isString, nullable, typedStruct } from \"is-kit\";\nconst isProfile = typedStruct>()({\n displayName: isString,\n bio: nullable(isString),\n});\nconst isAccount = typedStruct()({\n id: isString,\n profile: nullable(isProfile),\n tags: arrayOf(isString),\n});\n```\nThis is the model I like:\n\nReuse the existing type at compile time. Compose small guards at runtime.\n\n\nThe application type remains the source we want the guard to follow.\n\n## πŸ”’ What About Extra Runtime Properties?\n\nThere is another distinction worth making.\n\nThese are two different questions:\n\n1. Does my **guard definition** match the TypeScript type?\n2. Should a **runtime object** be allowed to contain additional properties?\n\nBy default, an object can still have additional keys.\n\nIf you want the runtime object shape to be closed as well, you can enable exact mode:\n\n\n```\nimport { isString, typedStruct } from \"is-kit\";\ntype User = {\n id: string;\n name: string;\n};\nconst isExactUser = typedStruct()(\n {\n id: isString,\n name: isString,\n },\n {\n exact: true,\n },\n);\n```\nThen:\n\n\n```\nisExactUser({\n id: \"user-1\",\n name: \"Ada\",\n});\n// true\nisExactUser({\n id: \"user-1\",\n name: \"Ada\",\n debug: true,\n});\n// false\n```\nWhether extra properties should be rejected is a runtime policy decision.\n\nIt shouldn't be confused with keeping the guard definition synchronized with the TypeScript type.\n\n## βš–οΈ Which Should Be the Source of Truth?\n\nI don't think there is one correct validation style for every project.\n\nThe important question is\n\nWhat already owns the shape of this data?\n\n\n### Manual predicate\n\n```\nconst isSomething = (value: unknown): value is Something => {\n // custom logic\n};\n```\nGreat when the validation is unusual or not primarily structural.\n\n### Guard-first\n\n```\nconst isUser = struct({\n id: isString,\n name: isString,\n});\n```\nUseful when the guard itself should define the resulting type.\n\n### Type-first\n\n```\nconst isUser = typedStruct()({\n id: isString,\n name: isString,\n});\n```\nUseful when `User` already exists and the runtime guard needs to stay aligned with it.\n\n### Schema-first\n\nA schema library or code generation may be the better source of truth when you need things like:\n\n- structured validation errors\n- coercion\n- transforms\n- defaults\n- generated artifacts\n\nThese solve different problems.\n\nI don't think every boolean validation check needs to become a schema. 😸\n\n\n## \n \n \n 🚫 What `typedStruct` Does Not Do\n\nThere are some important boundaries.\n\n`typedStruct` does **not** generate runtime validation from a TypeScript type.\n\nTypes are erased at runtime, so you still need to declare the guards you want to execute.\n\nIt also doesn't:\n\n- prove that every custom predicate is honest\n- coerce values\n- return rich structured validation errors\n- replace schema-first workflows\n- validate numeric or symbol properties as part of its string-keyed object contract\n\nIt's intentionally smaller than that.\n\nThe goal is simply to create a typed bridge between\n\nthe object type you already have\n\n\nand\n\nthe runtime guards you choose to run\n\n\n## 🎯 The Important Part\n\nThe main point isn't really `typedStruct`.\n\nIt's this\n\n**A type predicate is a promise, not a proof.**\n\n\nThis\n\n\n```\n(value): value is User\n```\ndoesn't mean TypeScript inspected your implementation and proved that every `User` field was validated.\n\nWe made that promise.\n\nSo when a TypeScript type is the source of truth, I think it's useful to make the runtime guard structurally depend on that type instead of relying on us to remember every future change.\n\nThat's what I wanted `typedStruct` to help with. 😸\n\nIf your guard defines the type, use a guard-first approach.\n\nIf an existing TypeScript type should define the contract, connect the guard to that type.\n\nAnd if you need rich parsing, transforms, coercion, or detailed errors, that's where a schema starts to earn its weight.\n\nI wrote a more complete guide about this on the is-kit documentation site:\n\nIf you like small reusable TypeScript type guards, `is-kit` is open source too!\n\n## nyaomaru / is-kit\n\n### Build small guards. Compose them. Lightweight, zero-dependency TypeScript type guards for runtime validation and natural narrowing. Runtime-safe πŸ›‘οΈ, composable 🧩, and ergonomic ✨.\n\n# is-kit\n\n## Build small guards. Compose them.\n\n`is-kit` is a lightweight, zero-dependency toolkit for building reusable TypeScript **type guards**.\n\nIt helps you write small `isFoo` functions, compose them into **richer runtime checks**, and keep **TypeScript narrowing** natural inside regular control flow.\n\n**Runtime-safe** πŸ›‘οΈ, **composable** 🧩, and **ergonomic** ✨ without asking you to adopt a heavy schema workflow.\n\n- Build and reuse **typed guards**\n- \n**Compose guards** with`and` ,`or` ,`not` ,`oneOf`\n- \n**Validate object** shapes and collections\n- \n**Parse or assert**`unknown` values without a large schema framework\n\nπŸ“š Documentation Site Β· 🧭 Practical Guides\n\nBest for **app-internal narrowing, filtering, and reusable guards**.\n\n\n## πŸ€” Why use `is-kit`?\n\nTired of rewriting the same `isFoo` checks again and again?\n\n`is-kit` is a good fit when you want to:\n\n- \n**write reusable `isX`** functions instead of one-off inline checks\n- keep runtime validation **lightweight and dependency-free**\n- \n**narrow values directly** in`if` ,`filter` …\n\nThanks for reading! πŸ™Œ","body_html":"

Your Type Guard Can Silently Drift from Your TypeScript Type

\n

Hoi hoi! πŸ‘‹

\n

I'm @nyaomaru, a frontend engineer just back from a short vacation on Texel, a small island in the Netherlands. 😸🏝️

\n

Today, let's talk about a type guard that looks completely safe.

\n
const isUser = (value: unknown): value is User => {\n  // runtime checks...\n};
\n

Looks good, right?

\n

TypeScript knows that when isUser(value) returns true, the value is a User.

\n

But there's a small problem

\n

TypeScript trusts that promise.

\n

It doesn't prove that your runtime checks actually validate every field in User.

\n

And that's where type guards can slowly drift away from the types they claim to protect.

\n

Let's take a look! πŸ‘€

\n

πŸ•³οΈ A Type Guard Can Become Outdated Without an Error

\n

Imagine we start with this type

\n
type User = {\n  id: string;\n  name: string;\n};
\n

And a hand-written type guard

\n
const isUser = (value: unknown): value is User => {\n  if (typeof value !== "object" || value === null) {\n    return false;\n  }\n  const candidate = value as Record<string, unknown>;\n  return typeof candidate.id === "string" && typeof candidate.name === "string";\n};
\n

So far, everything matches.

\n

Later, we update User

\n
type User = {\n  id: string;\n  name: string;\n  role: "admin" | "member";\n};
\n

But we forget to update the guard.

\n
const isUser = (value: unknown): value is User => {\n  if (typeof value !== "object" || value === null) {\n    return false;\n  }\n  const candidate = value as Record<string, unknown>;\n  return typeof candidate.id === "string" && typeof candidate.name === "string";\n};
\n

There is no role check.

\n

But this still compiles. 😿

\n

🧠 Why Doesn't TypeScript Catch This?

\n

Because this

\n
(value: unknown): value is User
\n

is a user-defined type predicate.

\n

You are telling TypeScript

\n

Trust me. If this function returns true, the value is a User.

\n

TypeScript can check whether the declared predicate type itself makes sense.

\n

But it cannot generally prove that arbitrary runtime logic actually validates every part of that type.

\n

So this is possible

\n
const isUser = (_value: unknown): _value is User => true;
\n

Terrible guard.

\n

Perfectly valid TypeScript. 😹

\n

The return type is a contract written by us, not a proof generated from the function body.

\n

πŸ”„ This Becomes a Maintenance Problem

\n

The annoying part isn't writing the guard once.

\n

It's keeping these two things synchronized over time

\n
TypeScript type\n      ↕\nRuntime validation
\n

Types change.

\n

Properties get

\n
  • added
  • removed
  • renamed
  • made optional
  • changed to another type
\n

And every time that happens, we need to remember that some runtime guard somewhere may also need an update.

\n

If we forget, the compiler may not tell us.

\n

That's the kind of bug I really don't want to rely on memory to prevent.

\n

βœ… What If the Type Could Be the Contract?

\n

This is one of the reasons I added typedStruct to is-kit.

\n

Suppose the application type already exists:

\n
type User = {\n  id: string;\n  name: string;\n  age?: number;\n};
\n

We can build the guard against that existing type

\n
import { isNumber, isString, optionalKey, typedStruct } from "is-kit";\nconst isUser = typedStruct<User>()({\n  id: isString,\n  name: isString,\n  age: optionalKey(isNumber),\n});
\n

Now the field map has a type-level relationship with User.

\n

At runtime, it still performs ordinary object validation.

\n

But at compile time, TypeScript can check whether the guards we declared match the object type they're supposed to follow.

\n

πŸ’₯ Now Drift Becomes Visible

\n

Let's add a field again

\n
type User = {\n  id: string;\n  name: string;\n  role: "admin" | "member";\n  age?: number;\n};
\n

But forget to update the guard

\n
typedStruct<User>()({\n  id: isString,\n  name: isString,\n  age: optionalKey(isNumber),\n  // TypeScript error:\n  // role is missing\n});
\n

Nice.

\n

The runtime bug became a compile-time problem.

\n

The same thing happens if the guard uses an incompatible field type

\n
import {\n  isNumber,\n  isString,\n  oneOfValues,\n  optionalKey,\n  typedStruct,\n} from "is-kit";\ntypedStruct<User>()({\n  id: isString,\n  name: isNumber,\n  // TypeScript error:\n  // User["name"] is string\n  role: oneOfValues("admin", "member"),\n  age: optionalKey(isNumber),\n});
\n

This is the part I care about most.

\n

typedStruct doesn't eliminate maintenance.

\n

It makes forgotten maintenance visible.

\n

🧩 Optional and Nullable Are Different

\n

Another place where object guards can get confusing is optional properties.

\n

Consider:

\n
type User = {\n  id: string;\n  nickname?: string | null;\n};
\n

There are two separate ideas here

\n
nickname may be absent
\n

and

\n
nickname may exist with the value null
\n

Those are different runtime contracts.

\n

With typedStruct

\n
import { isString, nullable, optionalKey, typedStruct } from "is-kit";\nconst isUser = typedStruct<User>()({\n  id: isString,\n  nickname: optionalKey(nullable(isString)),\n});
\n

Now

\n
isUser({ id: "user-1" });\n// true\nisUser({\n  id: "user-1",\n  nickname: null,\n});\n// true\nisUser({\n  id: "user-1",\n  nickname: "Neko",\n});\n// true\nisUser({\n  id: "user-1",\n  nickname: 42,\n});\n// false
\n

I like keeping these two decisions explicit:

\n
\n

optionalKey(...) β†’ the property may be absent

\n
\n

nullable(...) β†’ the value may benull

\n

They look similar at first, but they describe different things.

\n

🌳 Nested Types Don't Need to Be Duplicated Either

\n

Now imagine a larger type:

\n
type Account = {\n  readonly id: string;\n  readonly profile: {\n    readonly displayName: string;\n    readonly bio: string | null;\n  } | null;\n  readonly tags: readonly string[];\n};
\n

We could manually copy the profile shape into another type.

\n

But that creates another thing that can drift.

\n

Instead, we can reference the type we already have

\n
import { arrayOf, isString, nullable, typedStruct } from "is-kit";\nconst isProfile = typedStruct<NonNullable<Account["profile"]>>()({\n  displayName: isString,\n  bio: nullable(isString),\n});\nconst isAccount = typedStruct<Account>()({\n  id: isString,\n  profile: nullable(isProfile),\n  tags: arrayOf(isString),\n});
\n

This is the model I like:

\n

Reuse the existing type at compile time. Compose small guards at runtime.

\n

The application type remains the source we want the guard to follow.

\n

πŸ”’ What About Extra Runtime Properties?

\n

There is another distinction worth making.

\n

These are two different questions:

\n
  1. Does my guard definition match the TypeScript type?
  2. Should a runtime object be allowed to contain additional properties?
\n

By default, an object can still have additional keys.

\n

If you want the runtime object shape to be closed as well, you can enable exact mode:

\n
import { isString, typedStruct } from "is-kit";\ntype User = {\n  id: string;\n  name: string;\n};\nconst isExactUser = typedStruct<User>()(\n  {\n    id: isString,\n    name: isString,\n  },\n  {\n    exact: true,\n  },\n);
\n

Then:

\n
isExactUser({\n  id: "user-1",\n  name: "Ada",\n});\n// true\nisExactUser({\n  id: "user-1",\n  name: "Ada",\n  debug: true,\n});\n// false
\n

Whether extra properties should be rejected is a runtime policy decision.

\n

It shouldn't be confused with keeping the guard definition synchronized with the TypeScript type.

\n

βš–οΈ Which Should Be the Source of Truth?

\n

I don't think there is one correct validation style for every project.

\n

The important question is

\n

What already owns the shape of this data?

\n

Manual predicate

\n
const isSomething = (value: unknown): value is Something => {\n  // custom logic\n};
\n

Great when the validation is unusual or not primarily structural.

\n

Guard-first

\n
const isUser = struct({\n  id: isString,\n  name: isString,\n});
\n

Useful when the guard itself should define the resulting type.

\n

Type-first

\n
const isUser = typedStruct<User>()({\n  id: isString,\n  name: isString,\n});
\n

Useful when User already exists and the runtime guard needs to stay aligned with it.

\n

Schema-first

\n

A schema library or code generation may be the better source of truth when you need things like:

\n
  • structured validation errors
  • coercion
  • transforms
  • defaults
  • generated artifacts
\n

These solve different problems.

\n

I don't think every boolean validation check needs to become a schema. 😸

\n

##

\n

🚫 What typedStruct Does Not Do

\n

There are some important boundaries.

\n

typedStruct does not generate runtime validation from a TypeScript type.

\n

Types are erased at runtime, so you still need to declare the guards you want to execute.

\n

It also doesn't:

\n
  • prove that every custom predicate is honest
  • coerce values
  • return rich structured validation errors
  • replace schema-first workflows
  • validate numeric or symbol properties as part of its string-keyed object contract
\n

It's intentionally smaller than that.

\n

The goal is simply to create a typed bridge between

\n

the object type you already have

\n

and

\n

the runtime guards you choose to run

\n

🎯 The Important Part

\n

The main point isn't really typedStruct.

\n

It's this

\n

A type predicate is a promise, not a proof.

\n

This

\n
(value): value is User
\n

doesn't mean TypeScript inspected your implementation and proved that every User field was validated.

\n

We made that promise.

\n

So when a TypeScript type is the source of truth, I think it's useful to make the runtime guard structurally depend on that type instead of relying on us to remember every future change.

\n

That's what I wanted typedStruct to help with. 😸

\n

If your guard defines the type, use a guard-first approach.

\n

If an existing TypeScript type should define the contract, connect the guard to that type.

\n

And if you need rich parsing, transforms, coercion, or detailed errors, that's where a schema starts to earn its weight.

\n

I wrote a more complete guide about this on the is-kit documentation site:

\n

If you like small reusable TypeScript type guards, is-kit is open source too!

\n

nyaomaru / is-kit

\n

Build small guards. Compose them. Lightweight, zero-dependency TypeScript type guards for runtime validation and natural narrowing. Runtime-safe πŸ›‘οΈ, composable 🧩, and ergonomic ✨.

\n

is-kit

\n

Build small guards. Compose them.

\n

is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards.

\n

It helps you write small isFoo functions, compose them into richer runtime checks, and keep TypeScript narrowing natural inside regular control flow.

\n

Runtime-safe πŸ›‘οΈ, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow.

\n
  • Build and reuse typed guards
\n

Compose guards withand ,or ,not ,oneOf

\n
\n

Validate object shapes and collections

\n
\n

Parse or assertunknown values without a large schema framework

\n

πŸ“š Documentation Site Β· 🧭 Practical Guides

\n

Best for app-internal narrowing, filtering, and reusable guards.

\n

πŸ€” Why use is-kit?

\n

Tired of rewriting the same isFoo checks again and again?

\n

is-kit is a good fit when you want to:

\n
\n

write reusable isX functions instead of one-off inline checks

\n
  • keep runtime validation lightweight and dependency-free
\n

narrow values directly inif ,filter …

\n

Thanks for reading! πŸ™Œ

","headings":[{"level":1,"text":"Your Type Guard Can Silently Drift from Your TypeScript Type","id":"your-type-guard-can-silently-drift-from-your-typescript-type"},{"level":2,"text":"πŸ•³οΈ A Type Guard Can Become Outdated Without an Error","id":"a-type-guard-can-become-outdated-without-an-error"},{"level":2,"text":"🧠 Why Doesn't TypeScript Catch This?","id":"why-doesn-t-typescript-catch-this"},{"level":2,"text":"πŸ”„ This Becomes a Maintenance Problem","id":"this-becomes-a-maintenance-problem"},{"level":2,"text":"βœ… What If the Type Could Be the Contract?","id":"what-if-the-type-could-be-the-contract"},{"level":2,"text":"πŸ’₯ Now Drift Becomes Visible","id":"now-drift-becomes-visible"},{"level":2,"text":"🧩 Optional and Nullable Are Different","id":"optional-and-nullable-are-different"},{"level":2,"text":"🌳 Nested Types Don't Need to Be Duplicated Either","id":"nested-types-don-t-need-to-be-duplicated-either"},{"level":2,"text":"πŸ”’ What About Extra Runtime Properties?","id":"what-about-extra-runtime-properties"},{"level":2,"text":"βš–οΈ Which Should Be the Source of Truth?","id":"which-should-be-the-source-of-truth"},{"level":3,"text":"Manual predicate","id":"manual-predicate"},{"level":3,"text":"Guard-first","id":"guard-first"},{"level":3,"text":"Type-first","id":"type-first"},{"level":3,"text":"Schema-first","id":"schema-first"},{"level":2,"text":"🎯 The Important Part","id":"the-important-part"},{"level":2,"text":"nyaomaru / is-kit","id":"nyaomaru-is-kit"},{"level":3,"text":"Build small guards. Compose them. Lightweight, zero-dependency TypeScript type guards for runtime validation and natural narrowing. Runtime-safe πŸ›‘οΈ, composable 🧩, and ergonomic ✨.","id":"build-small-guards-compose-them-lightweight-zero-dependency-type"},{"level":1,"text":"is-kit","id":"is-kit"},{"level":2,"text":"Build small guards. Compose them.","id":"build-small-guards-compose-them"},{"level":2,"text":"πŸ€” Why use is-kit?","id":"why-use-is-kit"}]}}