Schema Validation with TypeScript

Schemas describe and verify actual runtime values at trust boundaries such as HTTP requests, forms, and JSON files. Libraries can help, but a small hand-written guard also shows the essential mechanism. Validate that an unknown value is an object and inspect each required property before giving it a trusted TypeScript type.

The first input has a finite positive number and an allowed currency. The second has a string amount, so parsePayment returns null rather than trusting the declared Payment type.

The expression value as Payment changes the compiler's view, but performs zero runtime checks.

This source was compiled using TypeScript 5.8.3 with strict checking, then executed with Node.js 22.16.0. Its stdout below is the actual captured output. The core logic is runnable without a framework or a remote API; integration-specific examples appear in a separate lab when needed.

TypeScript source

type Payment = { amount: number; currency: "INR" | "USD" };
function parsePayment(value: unknown): Payment | null {
  if (typeof value !== "object" || value === null) return null;
  if (!("amount" in value) || !("currency" in value)) return null;
  if (typeof value.amount !== "number" || !Number.isFinite(value.amount) || value.amount <= 0) return null;
  if (value.currency !== "INR" && value.currency !== "USD") return null;
  return { amount: value.amount, currency: value.currency };
}
console.log(parsePayment({ amount: 499, currency: "INR" }));
console.log(parsePayment({ amount: "499", currency: "INR" }));

Verified output

{ amount: 499, currency: 'INR' }
null

Compile: npx tsc --strict --target es2022 --module commonjs schema-validation.ts; run: node schema-validation.js. For examples importing node: modules, install @types/node as a development dependency; for browser or React projects use the separate lab setup.

The first input has a finite positive number and an allowed currency. The second has a string amount, so parsePayment returns null rather than trusting the declared Payment type.

Before editing the code, predict what the output will be for one changed input. Run it and compare your prediction with the actual result.

The expression value as Payment changes the compiler's view, but performs zero runtime checks.

Determine whether the issue belongs to the type system, a trust boundary, or actual runtime behavior before choosing a correction.

Extend the schema with an optional note field and reject non-string notes. Test empty, null, and extra input fields.

Record expected success and failure outcomes, run the code, and compare the observed behavior. Keep the exercise compatible with strict type checking.

The first input has a finite positive number and an allowed currency. The second has a string amount, so parsePayment returns null rather than trusting the declared Payment type.

Apply the same reasoning to the practice task, then integrate it into a real app only when the runtime and dependency setup are ready.