[{"_1":2,"_238":-5,"_239":-5},"loaderData",{"_3":4,"_77":78},"root",{"_5":6,"_7":-5,"_8":9,"_10":11,"_69":70},"theme","light","currentUser","currentPath","/","customDomain",{"_12":13,"_14":15,"_16":17,"_18":19,"_20":21,"_22":21,"_23":24,"_25":24,"_26":27,"_28":29,"_30":31,"_32":33,"_34":35,"_36":37,"_38":39},"id","35a6412a-04d0-494e-b953-ae50ae64f99d","userDomainName","fox","userPubKey","68d6e729ce108126a9a687a4c677b4f8861c5cd731d45383507e599ae5f442ac","domainAliasName","foxvector.com","icon","https://media4.giphy.com/media/JSenFL6p4xH25p6xwK/giphy.gif?cid=6c09b952k09mco2ber7mem9guy9djzjrw2gz6v9mas4x7hm5&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g","appleTouchIcon","title","The art of programming","description","image","https://i.postimg.cc/nhrq3Z0K/open-uri20150608-27674-1ymefwb-483d5487.png","themeColor","#d7ffe1","url","","createdAt",["D",1745005327205],"updatedAt",["D",1745005327205],"userId","9bca96ce-6475-44b8-a364-e3236d41b934","user",{"_12":37,"_40":15,"_41":15,"_42":43,"_25":44,"_45":21,"_46":47,"_48":49,"_50":27,"_51":52,"_53":-5,"_54":55,"_56":24,"_57":17,"_58":59,"_60":61,"_62":-5,"_63":64,"_65":52,"_66":52,"_32":67,"_34":68},"username","displayName","fullName","Fox Vector","The art of programming\nlive book and musings","avatarUrl","nip5","stas@layer3.press","website","https://foxvector.com","banner","bot",false,"birthday","blogDescription","live book and musings","blogTitle","publicKey","lightingAddress","angereddeal67@walletofsatoshi.com","tags",[],"perspective","enabled",true,"translate","deleted",["D",1745005327205],["D",1745005327205],"relays",[71,72,73,74,75,76],"wss://relay.primal.net","wss://nos.lol","wss://articles.layer3.news","wss://offchain.pub","wss://relay.damus.io","wss://nostr.mom","routes/_index",{"_79":80,"_219":15,"_220":52,"_38":-7,"_221":-7,"_222":-7,"_223":224,"_10":231},"articles",[81,162,191],{"_12":82,"_83":-5,"_84":-5,"_23":85,"_25":86,"_87":-5,"_88":89,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":98,"_99":31,"_100":101,"_102":103,"_104":105,"_106":52,"_66":52,"_107":64,"_108":109,"_110":111,"_112":-5,"_113":109,"_114":-5,"_115":-5,"_116":-5,"_117":-5,"_118":-5,"_119":-5,"_120":-5,"_62":-5,"_121":-5,"_122":-5,"_60":-5,"_123":124,"_125":-5,"_126":127,"_144":-5,"_145":146,"_156":64,"_32":157,"_34":158,"_36":-5,"_159":-5,"_160":161},"36e7f0e8-9571-4ee0-b680-a1d1a97f1e57","linkUrl","language","Zod v4","Zod v4, the latest iteration of the TypeScript-first schema validation library, introduces a suite of enhancements aimed at improving performance, developer experience, and flexibility. After over a year of development, Zod v4 is now stable and available for use","enclosure","imageUrl","https://i.ibb.co/C5GMmqqf/featured-e8a44f37-cd52-4485-9729-fa95654972e8.webp","imageCaption","imageCopyrightNotice","videoUrl","videoCaption","videoCopyrightNotice","videoEmbedType","content","contentEncoded","

🚀 Performance Improvements

Zod v4 delivers significant performance gains:

String parsing is up to 2.6 times faster.
Array parsing sees a 3x speed increase.
Object parsing is up to 7x faster.
TypeScript compilation performance has improved, with some operations reducing from 25,000 to 1,100 instantiations.
The core bundle size has been reduced by 2x, and the new @zod/mini package offers a 6.6x smaller footprint with functional tree-shaking. Zod+7Medium+7Basic Utils+7

🧩 New Features

1. z.interface() for Recursive Types

Defining recursive schemas is now more straightforward with z.interface(), eliminating the need for z.lazy():GitHub+5Basic Utils+5Medium+5

typescript
CopyEditconst Category = z.interface({
  name: z.string(),
  get subcategories() {
    return z.array(Category);
  }
});

This approach simplifies the creation of recursive structures. Basic Utils

2. File Schema Validation

Zod v4 introduces z.file() for validating File instances, allowing constraints on size and MIME type:Zod+3Basic Utils+3Zod+3

typescript
CopyEditconst fileSchema = z.file()
  .min(10_000) // Minimum size in bytes
  .max(1_000_000) // Maximum size in bytes
  .type(\"image/png\"); // MIME type

This feature is particularly useful for handling file uploads. Zod+3Zod+3Basic Utils+3

3. Metadata Registry

A new metadata system allows attaching strongly-typed metadata to schemas without polluting the schema definition itself. Metadata is stored in a separate registry:Zod

typescript
CopyEditimport { z } from \"zod/v4\";

const myRegistry = z.registry<{ title: string; description: string }>();
const emailSchema = z.string().email();
myRegistry.set(emailSchema, {
  title: \"Email Address\",
  description: \"A valid email address.\"
});

This separation enhances modularity and clarity in schema definitions.

4. Internationalization (i18n)

Zod v4 supports locale-based error messages through z.config(), facilitating internationalization:Medium+4Basic Utils+4Zod+4

typescript
CopyEditz.config(z.locales.en()); // Set to English locale

This feature allows developers to provide validation messages in multiple languages. Basic Utils

5. Enhanced Error Handling

The new z.prettifyError() function converts ZodError instances into human-readable strings, improving debugging and user feedback:Basic Utils

typescript
CopyEditconst result = schema.safeParse(data);
if (!result.success) {
  console.log(z.prettifyError(result.error));
}

This enhancement streamlines error reporting. Best of JS+11Reddit+11Medium+11

🔁 Migration and Compatibility

To adopt Zod v4, ensure your project is using zod@^3.25.0 or later. Zod v4 is accessible via the /v4 subpath:Hacker News+3Zod+3Zod+3

typescript
CopyEditimport { z } from \"zod/v4\";

This approach allows for a gradual migration, as Zod v3 and v4 can coexist.

📦 Additional Enhancements

z.stringbool(): Converts common truthy and falsy strings into boolean values, simplifying boolean parsing from user input.
Improved JSON Schema Conversion: Enhanced compatibility with validation tools and support for frontend-backend schema sharing.
Automatic Discriminator Detection: z.discriminatedUnion() now automatically detects the discriminator key, reducing boilerplate. Medium+4Basic Utils+4Zod+4

🎯 Conclusion

Zod v4 represents a significant advancement in schema validation for TypeScript, offering improved performance, enhanced features, and greater flexibility. Whether you're building APIs, forms, or complex data structures, Zod v4 provides the tools to write safer and more maintainable code.Basic Utils

For more information and detailed documentation, visit the official Zod v4 documentation.

","textContent","pubDate",["D",1748168496883],"state","published","strategy","unknown","locked","original","duplicatesCount",0,"duplicateVersion",811634,"originalArticleId","errorsCount","shortSummary","summary","bullets","persons","places","words","sentiment","subject","meta","eventId","1a6af6295afe0ee58212ebf3528605ef714a4200de302b266eddcf56fc7e6fd1","nostrRootEvent","event",{"_12":124,"_128":129,"_130":131,"_60":132,"_140":17,"_96":141,"_142":143},"sig","a769ad899a224ada53cf03860c8f65687673bd1a9b1c257bf08b1c82dc78513be8eeaef7fb8f27031c8c2bc49116e9450c5ed260a71474a79a7d04226ba426a2","kind",1,[133,136,137,138],[134,135],"r","https://fox.layer3.press/articles/36e7f0e8-9571-4ee0-b680-a1d1a97f1e57",[121,85],[26,89],[139,17,31],"p","pubkey","Zod v4\nZod v4, the latest iteration of the TypeScript-first schema validation library, introduces a suite of enhancements aimed at improving performance, developer experience, and flexibility. After over a year of development, Zod v4 is now stable and available for use\nhttps://fox.layer3.press/articles/36e7f0e8-9571-4ee0-b680-a1d1a97f1e57","created_at",1748168496,"markdown","kind30023",{"_12":147,"_128":148,"_130":149,"_60":150,"_140":17,"_96":155,"_142":143},"9ed037601cd9309aabde3a6c9179e9eea4c2cda8e285459900c4fb6c7d23f15f","4354466981c3746154658141183472279aee34e8a1c5c1e1d39429fdc88f0a2a93d98bf744bf817cc5a4f1f46540641b27e18a91503ff322241ca671b972bafd",30023,[151,152,153,154],[134,135],[121,85],[26,89],[139,17,31],"Zod v4\n\nhttps://fox.layer3.press/articles/36e7f0e8-9571-4ee0-b680-a1d1a97f1e57","publishedToNostr",["D",1748168496883],["D",1748168496883],"storyId","likes",2,{"_12":163,"_83":-5,"_84":-5,"_23":164,"_25":165,"_87":-5,"_88":166,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":167,"_99":31,"_100":168,"_102":103,"_104":105,"_106":52,"_66":52,"_107":64,"_108":109,"_110":169,"_112":-5,"_113":109,"_114":-5,"_115":-5,"_116":-5,"_117":-5,"_118":-5,"_119":-5,"_120":-5,"_62":-5,"_121":170,"_122":-5,"_60":-5,"_123":171,"_125":-5,"_126":172,"_144":182,"_145":183,"_156":64,"_32":189,"_34":190,"_36":-5,"_159":-5,"_160":161},"cdd71195-62a4-420b-9e24-e23d78b27452","The Adapter Pattern in TypeScript","In software development, flexibility and reusability are crucial. Often, we find ourselves working with components or APIs that don’t quite match the interfaces we need. This is where the Adapter Pattern shines.\nIn this article, we'll explore what the Adapter Pattern is, why it's useful, and how to implement it in TypeScript.","https://i.ibb.co/VW0HjkbH/Chat-GPT-Image-May-22-2025-03-58-51-PM.png","

What is the Adapter Pattern?

The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together. It acts as a bridge between two interfaces, enabling integration without modifying existing code.

In simple terms: it adapts one interface to another.

Real-World Analogy

Imagine you have a U.S. laptop charger and you travel to Europe. The charger plug won't fit into the European socket. You need a plug adapter to convert the U.S. plug into a European-compatible one. The charger stays the same, but the adapter allows it to work in a new context.

When to Use the Adapter Pattern

You want to use an existing class but its interface doesn't match your needs.
You want to create a reusable class that cooperates with classes of incompatible interfaces.
You need to integrate third-party APIs or legacy systems with your application.

Implementing the Adapter Pattern in TypeScript

Let’s go through a practical example.

Scenario

Suppose you’re developing a payment system. You already have a PaymentProcessor interface that your application uses. Now, you want to integrate a third-party payment gateway with a different method signature.

Step 1: Define the Target Interface

ts
CopyEdit// The interface your application expects
interface PaymentProcessor {
  pay(amount: number): void;
}

Step 2: Create an Adaptee (incompatible class)

ts
CopyEdit// A third-party library with a different method
class ThirdPartyPaymentGateway {
  makePayment(amountInCents: number): void {
    console.log(`Payment of $${amountInCents / 100} processed via third-party gateway.`);
  }
}

Step 3: Implement the Adapter

ts
CopyEdit// Adapter makes the third-party class compatible with PaymentProcessor
class PaymentAdapter implements PaymentProcessor {
  private gateway: ThirdPartyPaymentGateway;

  constructor(gateway: ThirdPartyPaymentGateway) {
    this.gateway = gateway;
  }

  pay(amount: number): void {
    const amountInCents = amount * 100;
    this.gateway.makePayment(amountInCents);
  }
}

Step 4: Use the Adapter in Client Code

ts
CopyEditconst thirdPartyGateway = new ThirdPartyPaymentGateway();
const adapter: PaymentProcessor = new PaymentAdapter(thirdPartyGateway);

// Application uses a standard interface
adapter.pay(25); // Output: Payment of $25 processed via third-party gateway.

Advantages of the Adapter Pattern

Decouples code from third-party implementations.
Promotes code reuse by adapting existing components.
Improves maintainability when dealing with legacy systems or libraries.

Class Adapter vs Object Adapter

In languages like TypeScript, which do not support multiple inheritance, the object adapter approach (shown above) is preferred. However, in classical OOP languages like C++, you may also see class adapters, which rely on inheritance.

Conclusion

The Adapter Pattern is a powerful tool in your design pattern arsenal, especially when dealing with incompatible interfaces. In TypeScript, it helps integrate third-party APIs and legacy systems seamlessly, keeping your code clean and extensible.

By learning and applying the Adapter Pattern, you can make your applications more robust and flexible—ready to adapt to ever-changing requirements.

",["D",1747922145321],976428,"Adapter Pattern","0e6b3230cd5881e01548d7e17a9162bf4a3876deeb299cca984cee5601b59920",{"_12":171,"_128":173,"_130":149,"_60":174,"_140":17,"_96":180,"_142":181},"34c336829a6871a07eafda456f78367459b1bf1dc27a76c7b8375a52558ac412b2669037ab4df0fa27c0410b6befe19341f82a16c3ec309d980e203c025bc3ff",[175,177,178,179],[134,176],"https://fox.layer3.press/articles/cdd71195-62a4-420b-9e24-e23d78b27452",[121,164],[26,166],[139,17,31],"The Adapter Pattern in TypeScript\n### What is the Adapter Pattern?\n\nThe Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together. It acts as a bridge between two interfaces, enabling integration without modifying existing code.\n\nIn simple terms: **it adapts one interface to another**.\n\n### Real-World Analogy\n\nImagine you have a U.S. laptop charger and you travel to Europe. The charger plug won't fit into the European socket. You need a **plug adapter** to convert the U.S. plug into a European-compatible one. The charger stays the same, but the adapter allows it to work in a new context.\n\n\n\n\n## When to Use the Adapter Pattern\n\n- You want to use an existing class but its interface doesn't match your needs.\n- You want to create a reusable class that cooperates with classes of incompatible interfaces.\n- You need to integrate third-party APIs or legacy systems with your application.\n\n\n\n\n## Implementing the Adapter Pattern in TypeScript\n\nLet’s go through a practical example.\n\n### Scenario\n\nSuppose you’re developing a payment system. You already have a `PaymentProcessor` interface that your application uses. Now, you want to integrate a third-party payment gateway with a different method signature.\n\n\n\n\n### Step 1: Define the Target Interface\n\n```javascript\nts\nCopyEdit// The interface your application expects\ninterface PaymentProcessor {\n pay(amount: number): void;\n}\n```\n\n\n\n\n### Step 2: Create an Adaptee (incompatible class)\n\n```javascript\nts\nCopyEdit// A third-party library with a different method\nclass ThirdPartyPaymentGateway {\n makePayment(amountInCents: number): void {\n console.log(`Payment of $${amountInCents / 100} processed via third-party gateway.`);\n }\n}\n```\n\n\n\n\n### Step 3: Implement the Adapter\n\n```javascript\nts\nCopyEdit// Adapter makes the third-party class compatible with PaymentProcessor\nclass PaymentAdapter implements PaymentProcessor {\n private gateway: ThirdPartyPaymentGateway;\n\n constructor(gateway: ThirdPartyPaymentGateway) {\n this.gateway = gateway;\n }\n\n pay(amount: number): void {\n const amountInCents = amount * 100;\n this.gateway.makePayment(amountInCents);\n }\n}\n```\n\n\n\n\n### Step 4: Use the Adapter in Client Code\n\n```javascript\nts\nCopyEditconst thirdPartyGateway = new ThirdPartyPaymentGateway();\nconst adapter: PaymentProcessor = new PaymentAdapter(thirdPartyGateway);\n\n// Application uses a standard interface\nadapter.pay(25); // Output: Payment of $25 processed via third-party gateway.\n```\n\n\n\n\n## Advantages of the Adapter Pattern\n\n- **Decouples code** from third-party implementations.\n- **Promotes code reuse** by adapting existing components.\n- **Improves maintainability** when dealing with legacy systems or libraries.\n\n\n\n\n## Class Adapter vs Object Adapter\n\nIn languages like TypeScript, which do not support multiple inheritance, the **object adapter** approach (shown above) is preferred. However, in classical OOP languages like C++, you may also see **class adapters**, which rely on inheritance.\n\n\n\n\n## Conclusion\n\nThe Adapter Pattern is a powerful tool in your design pattern arsenal, especially when dealing with incompatible interfaces. In TypeScript, it helps integrate third-party APIs and legacy systems seamlessly, keeping your code clean and extensible.\n\nBy learning and applying the Adapter Pattern, you can make your applications more robust and flexible—ready to adapt to ever-changing requirements.\nhttps://fox.layer3.press/articles/cdd71195-62a4-420b-9e24-e23d78b27452",1747922145,"### What is the Adapter Pattern?\n\nThe Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to work together. It acts as a bridge between two interfaces, enabling integration without modifying existing code.\n\nIn simple terms: **it adapts one interface to another**.\n\n### Real-World Analogy\n\nImagine you have a U.S. laptop charger and you travel to Europe. The charger plug won't fit into the European socket. You need a **plug adapter** to convert the U.S. plug into a European-compatible one. The charger stays the same, but the adapter allows it to work in a new context.\n\n\n\n\n## When to Use the Adapter Pattern\n\n- You want to use an existing class but its interface doesn't match your needs.\n- You want to create a reusable class that cooperates with classes of incompatible interfaces.\n- You need to integrate third-party APIs or legacy systems with your application.\n\n\n\n\n## Implementing the Adapter Pattern in TypeScript\n\nLet’s go through a practical example.\n\n### Scenario\n\nSuppose you’re developing a payment system. You already have a `PaymentProcessor` interface that your application uses. Now, you want to integrate a third-party payment gateway with a different method signature.\n\n\n\n\n### Step 1: Define the Target Interface\n\n```javascript\nts\nCopyEdit// The interface your application expects\ninterface PaymentProcessor {\n pay(amount: number): void;\n}\n```\n\n\n\n\n### Step 2: Create an Adaptee (incompatible class)\n\n```javascript\nts\nCopyEdit// A third-party library with a different method\nclass ThirdPartyPaymentGateway {\n makePayment(amountInCents: number): void {\n console.log(`Payment of $${amountInCents / 100} processed via third-party gateway.`);\n }\n}\n```\n\n\n\n\n### Step 3: Implement the Adapter\n\n```javascript\nts\nCopyEdit// Adapter makes the third-party class compatible with PaymentProcessor\nclass PaymentAdapter implements PaymentProcessor {\n private gateway: ThirdPartyPaymentGateway;\n\n constructor(gateway: ThirdPartyPaymentGateway) {\n this.gateway = gateway;\n }\n\n pay(amount: number): void {\n const amountInCents = amount * 100;\n this.gateway.makePayment(amountInCents);\n }\n}\n```\n\n\n\n\n### Step 4: Use the Adapter in Client Code\n\n```javascript\nts\nCopyEditconst thirdPartyGateway = new ThirdPartyPaymentGateway();\nconst adapter: PaymentProcessor = new PaymentAdapter(thirdPartyGateway);\n\n// Application uses a standard interface\nadapter.pay(25); // Output: Payment of $25 processed via third-party gateway.\n```\n\n\n\n\n## Advantages of the Adapter Pattern\n\n- **Decouples code** from third-party implementations.\n- **Promotes code reuse** by adapting existing components.\n- **Improves maintainability** when dealing with legacy systems or libraries.\n\n\n\n\n## Class Adapter vs Object Adapter\n\nIn languages like TypeScript, which do not support multiple inheritance, the **object adapter** approach (shown above) is preferred. However, in classical OOP languages like C++, you may also see **class adapters**, which rely on inheritance.\n\n\n\n\n## Conclusion\n\nThe Adapter Pattern is a powerful tool in your design pattern arsenal, especially when dealing with incompatible interfaces. In TypeScript, it helps integrate third-party APIs and legacy systems seamlessly, keeping your code clean and extensible.\n\nBy learning and applying the Adapter Pattern, you can make your applications more robust and flexible—ready to adapt to ever-changing requirements.",{"_12":171,"_128":173,"_130":149,"_60":184,"_140":17,"_96":180,"_142":181},[185,186,187,188],[134,176],[121,164],[26,166],[139,17,31],["D",1747922145321],["D",1747922145321],{"_12":192,"_83":-5,"_84":-5,"_23":193,"_25":194,"_87":-5,"_88":27,"_90":-5,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":195,"_99":31,"_100":196,"_102":103,"_104":105,"_106":52,"_66":52,"_107":64,"_108":109,"_110":197,"_112":-5,"_113":109,"_114":-5,"_115":-5,"_116":-5,"_117":-5,"_118":-5,"_119":-5,"_120":-5,"_62":-5,"_121":198,"_122":-5,"_60":-5,"_123":199,"_125":-5,"_126":200,"_144":210,"_145":211,"_156":64,"_32":217,"_34":218,"_36":-5,"_159":-5,"_160":131},"0cddbe7b-cce1-4271-82ab-f6f4973b165d","TypeScript Lies? The Hidden Risks of Using Predicates!","At first glance, a function like isString seems harmless. It tells TypeScript: \"If this function returns true, you can trust that the input is a string.\" But what TypeScript doesn’t do is verify the logic inside that function. You, the developer, are now responsible for proving that assertion is correct. TypeScript simply takes your word for it","

TypeScript predicates are not truly safe!

At first glance, a function like isString seems harmless. It tells TypeScript: \"If this function returns true, you can trust that the input is a string.\" But what TypeScript doesn’t do is verify the logic inside that function. You, the developer, are now responsible for proving that assertion is correct. TypeScript simply takes your word for it.

Let’s look at a subtly broken example:

function isUser(obj: any): obj is { name: string } {
    return 'name' in obj;
}

This function claims that any object with a name property is a valid User — but it doesn’t check the type of name, or whether the object is even non-null. So this passes:

const maybeUser = { name: null };
if (isUser(maybeUser)) {
    // TypeScript thinks maybeUser.name is a string
    maybeUser.name.toUpperCase(); // 💥 Runtime crash
}

TypeScript happily trusts that name is a string because that’s what the predicate promised. But the predicate logic didn’t deliver.

The Illusion of Safety

This is the core problem with type predicates: they are only as safe as the logic inside them, but TypeScript provides no enforcement. It's a handshake agreement between the developer and the compiler. If the developer breaks that agreement, the compiler still behaves as if nothing is wrong.

Even worse, TypeScript’s type system cannot validate the correctness of a predicate. It has no insight into whether the logic inside isUser is sound. This leads to a false sense of safety — one that doesn’t show up until runtime.

When Things Go Wrong

Here's another problematic scenario:

function isNumberArray(input: any): input is number[] {
    return Array.isArray(input);
}

This passes:

const data: unknown = [1, \"two\", 3];
if (isNumberArray(data)) {
    data.forEach(num => console.log(num.toFixed(2))); // 💥 Runtime crash on \"two\"
}

The type predicate says it's a number array — and TypeScript believes it. But it’s not.

Best Practices (or How to Tread Carefully)

Always validate all assumptions in your predicate — types, structure, null checks, etc.
Avoid writing broad predicates that pass easily; be specific.
Don’t over-trust predicates from third-party code unless you’ve audited their logic.
Consider using runtime validation libraries like Zod or io-ts for more robust checks.

Final Thoughts

TypeScript’s type guards and predicates are a powerful tool, but they are a double-edged sword. They can help narrow types and improve developer ergonomics, but they also introduce subtle bugs when misused. The compiler won’t warn you — and that’s the problem.

So use predicates with caution — and always assume they can lie.

",["D",1745044202308],832137,"Typescript","b21bad61283f89bc5fc2a2646a2f96db9c959c05bf685848a29fbe1b9e420bd5",{"_12":199,"_128":201,"_130":149,"_60":202,"_140":17,"_96":208,"_142":209},"ee62e301d013431fb232f0f09a3ea9c341c9346c1172979fb66dbe33ec4f387c69f5450035d22e8bf2599b3439bd574d20c8109083408ea84f93d583bf0ce68e",[203,205,206,207],[134,204],"https://fox.layer3.press/articles/0cddbe7b-cce1-4271-82ab-f6f4973b165d",[121,193],[26,27],[139,17,31],"TypeScript Lies? The Hidden Risks of Using Predicates!\n### TypeScript predicates are not truly safe!\n\nAt first glance, a function like `isString` seems harmless. It tells TypeScript: \"If this function returns true, you can trust that the input is a string.\" But what TypeScript *doesn’t* do is verify the logic inside that function. You, the developer, are now responsible for proving that assertion is correct. TypeScript simply takes your word for it.\n\nLet’s look at a subtly broken example:\n\n```javascript\nfunction isUser(obj: any): obj is { name: string } {\n return 'name' in obj;\n}\n```\n\nThis function claims that any object with a `name` property is a valid `User` — but it doesn’t check the type of `name`, or whether the object is even non-null. So this passes:\n\n```javascript\nconst maybeUser = { name: null };\nif (isUser(maybeUser)) {\n // TypeScript thinks maybeUser.name is a string\n maybeUser.name.toUpperCase(); // 💥 Runtime crash\n}\n```\n\nTypeScript happily trusts that `name` is a `string` because that’s what the predicate promised. But the predicate logic didn’t deliver.\n\n### The Illusion of Safety\n\nThis is the core problem with type predicates: **they are only as safe as the logic inside them**, but TypeScript provides **no enforcement**. It's a handshake agreement between the developer and the compiler. If the developer breaks that agreement, the compiler still behaves as if nothing is wrong.\n\nEven worse, TypeScript’s type system cannot validate the correctness of a predicate. It has no insight into whether the logic inside `isUser` is sound. This leads to a false sense of safety — one that doesn’t show up until runtime.\n\n### When Things Go Wrong\n\nHere's another problematic scenario:\n\n```javascript\nfunction isNumberArray(input: any): input is number[] {\n return Array.isArray(input);\n}\n```\n\nThis passes:\n\n```javascript\nconst data: unknown = [1, \"two\", 3];\nif (isNumberArray(data)) {\n data.forEach(num => console.log(num.toFixed(2))); // 💥 Runtime crash on \"two\"\n}\n```\n\nThe type predicate says it's a number array — and TypeScript believes it. But it’s not.\n\n### Best Practices (or How to Tread Carefully)\n\n- **Always validate all assumptions** in your predicate — types, structure, null checks, etc.\n- **Avoid writing broad predicates** that pass easily; be specific.\n- **Don’t over-trust predicates from third-party code** unless you’ve audited their logic.\n- Consider using **runtime validation libraries** like [Zod](https://github.com/colinhacks/zod) or [io-ts](https://github.com/gcanti/io-ts) for more robust checks.\n\n### Final Thoughts\n\nTypeScript’s type guards and predicates are a powerful tool, but they are a double-edged sword. They can help narrow types and improve developer ergonomics, but they also introduce subtle bugs when misused. The compiler won’t warn you — and that’s the problem.\n\n**So use predicates with caution — and always assume they can lie.**\nhttps://fox.layer3.press/articles/0cddbe7b-cce1-4271-82ab-f6f4973b165d",1745044202,"### TypeScript predicates are not truly safe!\n\nAt first glance, a function like `isString` seems harmless. It tells TypeScript: \"If this function returns true, you can trust that the input is a string.\" But what TypeScript *doesn’t* do is verify the logic inside that function. You, the developer, are now responsible for proving that assertion is correct. TypeScript simply takes your word for it.\n\nLet’s look at a subtly broken example:\n\n```javascript\nfunction isUser(obj: any): obj is { name: string } {\n return 'name' in obj;\n}\n```\n\nThis function claims that any object with a `name` property is a valid `User` — but it doesn’t check the type of `name`, or whether the object is even non-null. So this passes:\n\n```javascript\nconst maybeUser = { name: null };\nif (isUser(maybeUser)) {\n // TypeScript thinks maybeUser.name is a string\n maybeUser.name.toUpperCase(); // 💥 Runtime crash\n}\n```\n\nTypeScript happily trusts that `name` is a `string` because that’s what the predicate promised. But the predicate logic didn’t deliver.\n\n### The Illusion of Safety\n\nThis is the core problem with type predicates: **they are only as safe as the logic inside them**, but TypeScript provides **no enforcement**. It's a handshake agreement between the developer and the compiler. If the developer breaks that agreement, the compiler still behaves as if nothing is wrong.\n\nEven worse, TypeScript’s type system cannot validate the correctness of a predicate. It has no insight into whether the logic inside `isUser` is sound. This leads to a false sense of safety — one that doesn’t show up until runtime.\n\n### When Things Go Wrong\n\nHere's another problematic scenario:\n\n```javascript\nfunction isNumberArray(input: any): input is number[] {\n return Array.isArray(input);\n}\n```\n\nThis passes:\n\n```javascript\nconst data: unknown = [1, \"two\", 3];\nif (isNumberArray(data)) {\n data.forEach(num => console.log(num.toFixed(2))); // 💥 Runtime crash on \"two\"\n}\n```\n\nThe type predicate says it's a number array — and TypeScript believes it. But it’s not.\n\n### Best Practices (or How to Tread Carefully)\n\n- **Always validate all assumptions** in your predicate — types, structure, null checks, etc.\n- **Avoid writing broad predicates** that pass easily; be specific.\n- **Don’t over-trust predicates from third-party code** unless you’ve audited their logic.\n- Consider using **runtime validation libraries** like [Zod](https://github.com/colinhacks/zod) or [io-ts](https://github.com/gcanti/io-ts) for more robust checks.\n\n### Final Thoughts\n\nTypeScript’s type guards and predicates are a powerful tool, but they are a double-edged sword. They can help narrow types and improve developer ergonomics, but they also introduce subtle bugs when misused. The compiler won’t warn you — and that’s the problem.\n\n**So use predicates with caution — and always assume they can lie.**",{"_12":199,"_128":201,"_130":149,"_60":212,"_140":17,"_96":208,"_142":209},[213,214,215,216],[134,204],[121,193],[26,27],[139,17,31],["D",1745044202308],["D",1745044202308],"userSchema","isPublic","userWithoutDomain","guest","publicUser",{"_12":13,"_14":15,"_16":17,"_18":19,"_20":21,"_22":21,"_23":24,"_25":24,"_26":27,"_28":29,"_30":31,"_32":225,"_34":226,"_36":37,"_38":227},["D",1745005327205],["D",1745005327205],{"_12":37,"_40":15,"_41":15,"_42":43,"_25":44,"_45":21,"_46":47,"_48":49,"_50":27,"_51":52,"_53":-5,"_54":55,"_56":24,"_57":17,"_58":59,"_60":228,"_62":-5,"_63":64,"_65":52,"_66":52,"_32":229,"_34":230},[],["D",1745005327205],["D",1745005327205],{"_12":13,"_14":15,"_16":17,"_18":19,"_20":21,"_22":21,"_23":24,"_25":24,"_26":27,"_28":29,"_30":31,"_32":232,"_34":233,"_36":37,"_38":234},["D",1745005327205],["D",1745005327205],{"_12":37,"_40":15,"_41":15,"_42":43,"_25":44,"_45":21,"_46":47,"_48":49,"_50":27,"_51":52,"_53":-5,"_54":55,"_56":24,"_57":17,"_58":59,"_60":235,"_62":-5,"_63":64,"_65":52,"_66":52,"_32":236,"_34":237},[],["D",1745005327205],["D",1745005327205],"actionData","errors"]

The art of programming

live book and musings

May, 2025

Zod v4

Adapter Pattern

The Adapter Pattern in TypeScript

Typescript

TypeScript Lies? The Hidden Risks of Using Predicates!