Zod 4 रिलीज़

 (zod.dev)
1 पॉइंट द्वारा GN⁺ 2025-05-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Zod 4 एक साल के विकास के बाद stable version के रूप में जारी हुआ है, जिसमें Zod 3 की design limitations को ठीक किया गया और performance, bundle size, TypeScript compile efficiency में बड़ा सुधार किया गया
  • मई 2021 में आया Zod 3 GitHub पर 2,700 stars और 6 लाख weekly downloads से बढ़कर अब 37.8k stars और 3.1 करोड़ weekly downloads तक पहुंच गया है; 24 minor versions के बाद बड़े सुधारों के लिए breaking changes ज़रूरी हो गए थे
  • benchmarks में string parsing 14 गुना, array parsing 7 गुना, object parsing 6.5 गुना तेज़ हुई; tsc type instantiation भी एक simple example में 25,000 से अधिक बार से घटकर लगभग 175 बार रह गई
  • core bundle size gzip के आधार पर Zod 3 के 12.47kb से घटकर Zod 4 regular version में 5.36kb हो गया, और tree-shaking योग्य functional API Zod Mini में यह 1.88kb तक छोटा हो गया
  • नए features में JSON Schema conversion, metadata registry, recursive object type inference, internationalization, error pretty-printing, template literal types, z.stringbool(), unified error parameter, improved z.discriminatedUnion() आदि शामिल हैं

Zod 4 के नए major version बनने की वजह

  • Zod 4 एक साल के सक्रिय development के बाद stable version बना है, और तेज़, छोटा व बेहतर tsc efficiency वाला आधार देकर लंबे समय से मांगे जा रहे features लागू करता है
  • Zod v3.0 मई 2021 में release हुआ था; उस समय GitHub stars 2,700 और weekly downloads 6 लाख थे
  • आज Zod के GitHub stars 37.8k और weekly downloads 3.1 करोड़ हैं
    • beta आने से 6 हफ्ते पहले weekly downloads 2.3 करोड़ थे
  • 24 minor versions जुड़ने के बाद Zod 3 codebase अपनी सीमा पर पहुंच गया था, और सबसे अधिक मांगे गए features व improvements के लिए breaking changes की जरूरत थी
  • Zod 4 ने सबसे ज्यादा upvotes पाने वाले public issues में से 10 में 9 को बंद किया

Parsing performance और TypeScript compile efficiency

  • Zod 4 repository में सीधे चलाए जा सकने वाले benchmarks देता है
  • parsing performance improvements:
    • string parsing: 14 गुना तेज़
    • array parsing: 7 गुना तेज़
    • object parsing: 6.5 गुना तेज़
  • object parsing benchmark Moltar validation library benchmark चलाता है
  • tsc --extendedDiagnostics के आधार पर simple file compile में type instantiation काफी कम हुई
    • "zod/v3" इस्तेमाल करने पर 25,000 से अधिक बार
    • "zod/v4" इस्तेमाल करने पर लगभग 175 बार
  • Zod 4 ने ZodObject और दूसरी schema classes के generics को redesign और simplify करके instantiation explosion से बचाव किया
  • .extend() और .omit() को बार-बार chain करने वाला pattern Zod 3 में compile होने में 4000ms लेता था, और अतिरिक्त .extend() call "Possibly infinite" error पैदा कर सकता था
  • वही pattern Zod 4 में 400ms में compile होता है, यानी 10 गुना तेज़
  • भविष्य में tsgo compiler के साथ इस्तेमाल करने पर Zod 4 की editor performance और बड़े schemas व codebases तक scale हो सकती है

Bundle size और Zod Mini

  • simple z.boolean() validation script को rollup से bundle करके core bundle size की तुलना की गई
  • gzip के आधार पर core bundle size:
    • Zod 3: 12.47kb
    • Zod 4 regular version: 5.36kb
  • Zod 4 regular version का core bundle Zod 3 से लगभग 57% छोटा है, यानी 2.3 गुना कम
  • Zod का method-centric API मूल रूप से tree-shaking के लिए कठिन है, और simple z.boolean() script भी .optional(), .array() जैसे unused method implementations को साथ खींच लाती है
  • Zod Mini zod से 1:1 match करने वाला functional और tree-shaking योग्य API देता है
    • जहां Zod methods इस्तेमाल करता है, वहां Zod Mini आम तौर पर wrapper functions इस्तेमाल करता है
    • parsing methods Zod और Zod Mini में समान हैं
    • general-purpose .check() method से refinement जोड़ा जाता है
  • regular Zod अधिकतर use cases के लिए अब भी recommended है, और जिन projects में असामान्य रूप से सख्त bundle size constraints हैं वे Zod Mini पर विचार कर सकते हैं
  • zod/mini इस्तेमाल करने पर gzip bundle size 1.88kb है
    • Zod 3 की तुलना में 85%, यानी 6.6 गुना कमी
    • comparison table: Zod 3 12.47kb, Zod 4 regular 5.36kb, Zod 4 Mini 1.88kb
  • अधिक जानकारी zod/mini docs में देखी जा सकती है

Metadata और JSON Schema

  • Zod 4 schemas में strongly typed metadata जोड़ने के लिए नया system लाता है
  • metadata schema में ही नहीं, बल्कि schema और typed metadata को जोड़ने वाली schema registry में store होता है
  • z.registry() से registry बनाई जा सकती है, और schema के .register() method से convenient registration भी संभव है
  • Zod common JSON Schema-compatible metadata लेने वाली global registry z.globalRegistry export करता है
  • .meta() method schema को z.globalRegistry में आसानी से जोड़ता है
  • Zod 3 compatibility के लिए .describe() उपलब्ध रहता है, लेकिन Zod 4 में .meta() recommended है
  • Zod 4 z.toJSONSchema() के जरिए first-party JSON Schema conversion देता है
  • z.globalRegistry का metadata JSON Schema output में automatically शामिल होता है
  • generated JSON Schema customization की जानकारी JSON Schema docs में है

नए schema expressions और type features

  • Zod 4 recursive object types को सही तरीके से infer कर सकता है
    • recursive types और mutually recursive types express किए जा सकते हैं
    • Zod 3 के recursive type pattern के विपरीत type casting की जरूरत नहीं है
    • result schema सामान्य ZodObject instance है और सभी methods इस्तेमाल किए जा सकते हैं
  • File instances validate करने के लिए File schema जोड़ा गया है
  • z.templateLiteral() TypeScript के template literal types को express करता है
    • stringified किए जा सकने वाले Zod schema types internal regex store करते हैं
    • targets में strings, z.email() जैसे string formats, numbers, boolean, bigint, enum, literal, undefined/optional, null/nullable, दूसरे template literal शामिल हैं
    • z.templateLiteral constructor इन्हें एक super-regex में जोड़ता है
    • z.email() जैसे string formats ठीक से enforce होते हैं, लेकिन custom refinement enforce नहीं होता
    • अधिक जानकारी template literal docs में है
  • fixed-width integers और floating-point types express करने वाले नए number formats जोड़े गए हैं
    • ये ऐसा ZodNumber instance लौटाते हैं जिसमें उचित inclusive minimum/maximum constraints पहले से जोड़े गए होते हैं
  • JavaScript number से सुरक्षित रूप से represent की जा सकने वाली range से बाहर के bigint number formats भी जोड़े गए हैं
    • ये ऐसा ZodBigInt instance लौटाते हैं जिसमें उचित inclusive minimum/maximum constraints पहले से जोड़े गए होते हैं
  • z.literal() अब optionally कई values ले सकता है

Errors, internationalization, string formats

  • Zod 4 error messages को कई भाषाओं में globally translate करने के लिए नया locales API पेश करता है
  • supported locales की पूरी list Customizing errors में है, और supported languages जुड़ने पर update होती है
  • Zod ने ZodError को user-friendly formatted string में बदलने वाला top-level z.prettifyError function implement किया है
    • current format configurable नहीं है
    • भविष्य में बदल सकता है
    • अगर मौजूदा zod-validation-error इस्तेमाल कर रहे हैं, तो उसे जारी रख सकते हैं
  • email आदि सभी string formats को z module के top-level functions में promote किया गया है
    • यह अधिक concise और tree-shaking के लिए बेहतर है
    • z.string().email() जैसा method counterpart API अब भी इस्तेमाल किया जा सकता है, लेकिन deprecated है
    • अगले major version में हटाया जाएगा
  • z.email() API custom regular expression support करता है
    • कोई एक canonical email regex तय नहीं है, और हर application अधिक सख्त या ढीले criteria चुन सकता है
    • convenience के लिए Zod कुछ common regex export करता है

Boolean conversion और error customization का सरलीकरण

  • मौजूदा z.coerce.boolean() falsy values को false और truthy values को true में बदलने वाला simple API है
    • false, undefined, null, 0, "", NaN आदि false बनते हैं
    • यह behavior दूसरे z.coerce APIs से मेल खाता है
  • env-style की अधिक sophisticated boolean coercion के लिए Zod 4 z.stringbool() पेश करता है
    • truthy और falsy values customize की जा सकती हैं
    • अधिक जानकारी z.stringbool() docs में है
  • Zod 4 के अधिकांश breaking changes error customization API से जुड़े हैं
  • error customization को single error parameter में unify किया गया है
    • message को error से replace किया गया है
    • message parameter अब भी supported है, लेकिन deprecated है
    • invalid_type_error और required_error को function syntax वाले error से replace किया गया है
    • errorMap को भी function syntax वाले error से replace किया गया है

Composability, refinements, transforms

  • z.discriminatedUnion() अब कई ऐसे schema types support करता है जो पहले support नहीं थे
    • इसमें union और pipe शामिल हैं
    • discriminated union को किसी दूसरे discriminated union का member बनाया जा सकता है, जिससे यह composable हो गया है
  • Zod 3 में refinements original schema को wrap करने वाली ZodEffects class में store होते थे
    • इस structure के कारण .refine() को .min() जैसे दूसरे schema methods के साथ mix करके इस्तेमाल करना असुविधाजनक था
  • Zod 4 में refinements schema के अंदर store होते हैं, इसलिए .refine() और दूसरे schema methods को सहज रूप से साथ इस्तेमाल किया जा सकता है
  • नया .overwrite() method ऐसा transform express करता है जो inferred type नहीं बदलता
    • .transform() का output type runtime में introspectable नहीं होता, और transform function कुछ भी return कर सकता है, इसलिए यह black box है
    • इसी कारण इसे JSON Schema में सुरक्षित रूप से convert करने का कोई तरीका नहीं है
    • .overwrite() original class का instance लौटाता है
    • overwrite function refinement के रूप में store होता है और inferred type को modify नहीं करता
  • मौजूदा .trim(), .toLowerCase(), .toUpperCase() को .overwrite() इस्तेमाल करके फिर से implement किया गया है

Library authors के लिए आधार

  • Zod Mini जुड़ने से zod/v4/core subpackage बनाया गया है, जिसमें Zod और Zod Mini द्वारा share की गई core functionality है
  • zod/v4/core Zod को simple library से आगे बढ़ाकर दूसरी libraries में embedded किए जा सकने वाले fast validation foundation में बदलता है
  • अगर schema library बना रहे हैं, तो Zod और Zod Mini implementations देखकर zod/v4/core के ऊपर build कर सकते हैं
  • library authors के लिए For library authors guide उपलब्ध है
    • यह Zod के ऊपर build करते समय best practices बताती है
    • Zod 3, Zod 4 और Mini को साथ-साथ support करने के तरीकों पर common questions के जवाब देती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-20
Hacker News की राय

  • मैं लेखक हूँ, कुछ भी पूछिए। version policy के बारे में इस approach की वजह काफी विस्तार से यहाँ लिखी है: https://github.com/colinhacks/zod/issues/4371
    आखिरकार npm को Zod जैसी स्थिति को अच्छी तरह संभालने के लिए design नहीं किया गया है। दर्जनों से सैकड़ों libraries Zod के interfaces/classes को सीधे import करके अपने public API में इस्तेमाल कर रही हैं, इसलिए जब भी Zod major version बढ़ाता है, उन libraries को भी नया major version निकालना पड़ता है
    अकेले में देखें तो यह reasonable है, लेकिन Zod में इससे सबके लिए दर्दनाक version avalanche हो सकता था, और लगा कि ecosystem का बड़ा हिस्सा हमेशा के लिए v3 पर pinned रह जाएगा
    इसलिए Go वाले तरीके जैसा, package का नया breaking-compatibility version निकालने के बजाय नया subpath जोड़ने का तरीका चुना। TypeScript ecosystem में कोई library सिर्फ zod@^3.25.0 को peer dependency रखकर "zod/v3" और "zod/v4" से अपनी जरूरत की चीजें import कर दोनों versions को साथ-साथ support कर सकती है

    • बड़े codebase में tsc performance improvement खास तौर पर स्वागतयोग्य है, और discriminated union में बदलाव भी अब तक कमजोर रहे कुछ खास scenarios में काफी मदद करेगा
      हालांकि खास परिस्थितियों के कारण कुछ अजीब version policy चुनने की वजह समझ आती है, लेकिन जिन teams को transitive dependency में Zod version conflicts की चिंता नहीं करनी पड़ती, उनके लिए 4.0.0 package भी होता तो अच्छा था
      अगर मैंने सही समझा है तो import को "zod/v4" में बदलना होगा, जो बहुत noisy change है, और IDE के 'zod' से auto import करने की समस्या को lint rule से पकड़ना पड़ेगा, जो सिरदर्द हो सकता है
    • यह तरीका बहुत reasonable है। इसका मतलब है कि पुराने version के security updates भी उसी codebase release के अंदर साथ में दिए जा सकते हैं
    • मोबाइल पर हूँ, इसलिए नहीं देख पाया कि लेख में यह पहले से है या नहीं, लेकिन सोच रहा हूँ कि TypeScript में .optional() को ठीक करने का काम top 9–10 issues के समाधान में शामिल है या नहीं: https://github.com/colinhacks/zod/issues/635
      Zod में यह मेरी सबसे बड़ी तकलीफ रही है, लेकिन Zod इतना अच्छा है कि इसे सहते हुए इस्तेमाल कर रहा हूँ
    • नए features की वजह से लगता है कि local में किए हुए कई temporary hacks हटा सकूँगा। form name typos से बचने के लिए मैं https://github.com/raflymln/zod-key-parser का अपना version इस्तेमाल कर रहा हूँ, और हैरानी हुई कि ऐसी functionality सीधे library में नहीं है
      जानना चाहता हूँ कि आप इसे Zod के scope से बाहर मानते हैं, या बस अभी implement करने का समय नहीं मिला। संबंधित चर्चा https://github.com/colinhacks/zod/discussions/2134 में है
    • अगर इसका मतलब है कि Zod 4 का सबसे शुरुआती version 3.25.0 है, तो यह थोड़ा बेतुका लगता है
      मैं कई महीनों से Zod alpha version इस्तेमाल कर रहा था और बस package.json बदलकर upgrade करना चाहता था, लेकिन अब लगता है कि पूरी git history खंगालनी पड़ेगी
      project के लिए बहुत आभारी हूँ, लेकिन इस feedback के मामले में लगता है कि इसे जरूरत से ज्यादा कठिन बना दिया गया। शायद 3.x के साथ 4.x भी publish किया जा सकता था

  • “migration को आसान बनाने के लिए Zod 4 को zod@3.25 release के हिस्से के रूप में Zod 3 के साथ ship करना, और "/v4" subpath से import कराना” यह संकेत लगता है कि npm dependency management पूरी तरह गड़बड़ है
    peer dependencies इतनी टूटी हुई हैं कि v4 को v3 होने का दिखावा करना पड़ रहा है

    • मैं लेखक हूँ। इस approach की वजह यहाँ काफी विस्तार से लिखी है: https://github.com/colinhacks/zod/issues/4371
      यह सही है कि npm Zod जैसी स्थिति को अच्छी तरह manage नहीं करता। हालांकि Zod पर यह constraint है कि वह लगभग कोई library स्वीकार नहीं करता। दर्जनों से सैकड़ों libraries "zod" से interfaces/classes को सीधे import करके अपने public API में इस्तेमाल करती हैं
      ऐसी libraries को Zod के हर major version bump पर नया major version निकालना पड़ता है, और Zod में यह version avalanche पैदा कर सकता है जो सबके लिए दर्दनाक होता। ईमानदारी से कहूँ तो लगा कि ecosystem का बड़ा हिस्सा हमेशा के लिए v3 पर pinned रह जाएगा
      इसलिए Go जैसा, हर breaking-compatibility release के लिए नया package version निकालने के बजाय नया subpath जोड़ने का तरीका चुना। TypeScript ecosystem में zod@^3.25.0 की एक peer dependency से "zod/v3" और "zod/v4" दोनों को साथ-साथ support किया जा सकता है
    • “peer dependencies टूट गई हैं इसलिए v4, v3 होने का दिखावा कर रहा है” वाला निष्कर्ष सही नहीं लगता। मुझे लगता है Zod v4 को v3 के अंदर इसलिए शामिल किया गया है ताकि users धीरे-धीरे migrate कर सकें
      यानी usage sites को एक-एक करके import ... from 'zod/v4' में refactor करें, और अंत में पूरी तरह v4 पर चले जाएँ
    • लगता है जो भी negative बात हो, उसे upvote मिल रहा है। यह फैसला npm की intrinsic limitation से ज्यादा, बहुत सारी breaking changes वाली libraries को gradual तरीके से बदलने देने का practical तरीका है
    • कई सालों से सिर्फ npm इस्तेमाल करने के कारण शायद मेरी दृष्टि सीमित हो गई हो, लेकिन v3 से v4 पर एक ही बड़े jump के बजाय iterative migration करने का इससे बेहतर तरीका क्या होगा, यह जानना चाहूँगा
    • यह सिर्फ npm की समस्या नहीं है। किसी dependency का किसी दूसरी transitive dependency में पुराने version पर निर्भर होना असल में लगभग हर ecosystem में होता है
      बल्कि npm में जरूरत पड़ने पर कई versions साथ-साथ चला सकते हैं या transitive dependency graph के कुछ हिस्से selectively override कर सकते हैं, इसलिए escape routes ज्यादा हैं
      कौन-सा package management system इस समस्या को हल करता है? Maven जैसे “stable” platforms भी Apache Commons के v2 से v3 जाने पर नए namespace के साथ version निकालकर ऐसी समस्याएँ संभालते हैं

  • एक सवाल मुझे बहुत पहले से परेशान करता रहा है। सुना है कि Zod इसमें फिट हो सकता है, लेकिन docs देखने के बाद भी ठीक से समझ नहीं आता कि करना कैसे है
    मान लीजिए server API उससे ज़्यादा refined type लौटाता है जितना वह सीधे express कर सकता है। उदाहरण के लिए api/:postid/author User लौटाता है, लेकिन वह सामान्य User भी हो सकता है और anonymous User भी, इसलिए username, location जैसे fields null आ सकते हैं। इस स्थिति में User object को discriminated union के रूप में express करना चाह सकते हैं
    दूसरे endpoints से आने वाले objects को भी type conversion की ज़रूरत हो सकती है। User कभी-कभी Post[] शामिल करता है, और अगर Post moderator की post है तो उसमें special properties भी हो सकती हैं
    पहले मैं normalizeUser() और normalizePost() जैसे functions लिखता था, लेकिन वे जल्दी ही messy हो गए। हर endpoint User/Post model के अलग-अलग subsets लौटाता था, इसलिए normalizePost के करीब 5 variants बनाने पड़े, जो बहुत बिखरा हुआ था। जानना चाहता हूँ कि ऐसी समस्या आम तौर पर कैसे हल की जाती है

    • लगता है discriminated union इस्तेमाल किया जा सकता है
      status जैसे discriminator field के आधार पर success और failed objects को अलग करने जैसा। अगर moderator के लिए बहुत सारी special properties हैं, लेकिन आप उन्हें सब list या check नहीं करना चाहते, तो passthrough behavior define कर सकते हैं
      भले ही अलग-अलग methods के schemas अलग हों, अगर उनमें common हिस्सा है तो shared object schema बनाकर उस पर extra fields वाले objects बनाए जा सकते हैं। possibilities बहुत हों तो फिर भी messy रहेगा, लेकिन अगर हालात पहले से messy हैं तो validator कम से कम उस mess को validate तो कर सकता है
    • Ideally, User किस-किस shape में हो सकता है इसके लिए single source of truth होना चाहिए। यह User और AnonymousUser जैसा discriminated union हो सकता है
      अगर full-stack TypeScript नहीं है, तो उदाहरण के लिए Python backend में अलग-अलग User shapes को Pydantic models और unions से define किया जा सकता है, और OpenAPI/GraphQL schema generation व code generation के जरिए TypeScript client types बनाए जा सकते हैं
    • use case को और समझना पड़ेगा, लेकिन union के हर type में "user_type" जैसी discriminating property जोड़ दें तो सामान्य और special cases को handle करना आसान हो जाता है
      उदाहरण के लिए user.user_type === 'authenticated' check करने पर type system समझ जाता है कि उसके बाद user.name इस्तेमाल किया जा सकता है
    • यह अभी की स्थिति में सीधे मददगार नहीं है, लेकिन GraphQL इसी तरह की चीज़ों के लिए बनाया गया था
      GraphQL queries के लिए TypeScript libraries चुने गए fields के shape से response shape को dynamically infer कर सकती हैं। { user { username posts { text } } } चुनने पर response type में posts होगा, और अगर सिर्फ { user { username } } चुनें तो posts property पूरी तरह गायब रहेगी
    • server को types export करने चाहिए। client में types हाथ से लिखना कोई मायने नहीं रखता
      server जानता है कि वह कौन-सा data भेज रहा है, इसलिए उसे वह जानकारी metadata के रूप में client को देनी चाहिए। Practical तौर पर इसका मतलब हो सकता है कि Python backend Pydantic schema इस्तेमाल करे, उसके आधार पर OpenAPI spec auto-generate करे, और client types generate करे

  • Zod देखे गए alternatives से काफी बेहतर है, लेकिन कभी-कभी यह बात ही कि ऐसी explicit validation की ज़रूरत पड़ती है, आधुनिक web development कहाँ पहुँच गया है इसकी असफलता जैसी लगती है
    full-stack development में उसी shape को कई तरीकों से describe करना बहुत frustrating है। JS input validation, API definitions के लिए Swagger, server-side input validation, schema compatibility के लिए ORM, और server व client की अलग-अलग TypeScript definitions तक चाहिए होती हैं—सब बहुत tedious है

    • TypeScript का static checking/compile-time-only system पर अड़े रहना पूरे ecosystem के लिए दुखद घाव जैसा है। मैं नहीं चाहता कि TypeScript runtime checker बन जाए, लेकिन इच्छा है कि वह classes, functions और objects के लिए उपयोगी type data export करे
      TypeScript हमारे पास मौजूद सबसे अच्छा single source of truth जैसा लगता है, लेकिन असल में reflection की कोशिश करने वाले tools अपनी-अपनी models और builders फिर से define कर रहे हैं। reflection core होने वाले बड़े क्षेत्रों की संख्या ही 5 है, और हर एक की कई implementations हैं
      पुराना TypeScript type emission tool reflect-metadata runtime type information का कुछ हिस्सा देता है, लेकिन वह बहुत पुराने decorators और metadata spec को target करता है: https://www.npmjs.com/package/reflect-metadata
      शायद हम integration की शुरुआती अवस्था में हों। Standard Schema project को ज़्यादातर प्रमुख validation libraries का support मिलता दिखता है। हालांकि इसे API definition या ORM tools तक फैलाना अभी बहुत शुरुआती चरण में है
      https://github.com/standard-schema/standard-schema?tab=readm...
    • असल में ऐसे tools का core यही है। एक बार define करें, और उसके नीचे की हर चीज़ dynamically generate कर दें
      Zod schema में एक बार बदलाव करने पर वह type checking के साथ पूरे app में propagate हो जाता है। यानी Zod schema single source of truth बन जाता है
    • आम तौर पर data को हर जगह फिर से define करने की ज़रूरत नहीं होती। Zod में convert करने या Zod से convert करने वाले tools बहुत ज़्यादा हैं
      अगर आपके पास पहले से JSON Schema/Swagger schema है, तो उससे Zod generate कर लें। अगर TypeScript ORM इस्तेमाल कर रहे हैं, तो लगभग निश्चित रूप से कोई Zod generator होगा
      सच कहूँ तो Zod इतना widely used है कि मेरे लिए यह वह unified schema definition बन गया है जिस पर stack की बाकी चीज़ें depend कर सकती हैं। types सीधे define होते हैं, इसलिए developers उन्हें सच में up to date रखते हैं। कंपनी का Swagger documentation बदलावों से हमेशा पीछे रहता है
    • सभी APIs experimental हैं और लगातार बदलती व evolve होती रहती हैं, web भी वैसा ही है
      status quo ठीक तभी लगता है जब आप ऐसे clients और employers से deal कर रहे हों जिन्हें बस result चाहिए और method से मतलब नहीं। उस context में complexity की ये दुर्भाग्यपूर्ण layers कम से कम billable hours बढ़ा देती हैं
    • modern web development की complexity पर शिकायत करने वालों में से काफी लोग इस सारे setup को सिर्फ TypeScript और Zod से replace करने के प्रस्ताव से भी चिढ़ जाएंगे
      बेशक, इस assumption पर कि Zod उनकी चुनी हुई TypeScript schema definition और validation library है

  • Zod 4 अच्छा दिखता है, लेकिन नवीनतम सुधारों के बावजूद ArkType अभी भी कई गुना—single-digit multiple—तेज़ है
    backward compatibility और syntax compatibility के लिए कभी-कभी किसी पूरी तरह नए सिरे से बनी library जितना तेज़ बनाना मुश्किल होता है। हाल के project में मैंने इन सभी tools का विश्लेषण किया था, और आंशिक रूप से इसी वजह से ArkType चुना। TypeScript का उपयोग-अनुभव भी बेहतर लगा

    • मैंने speed metrics देखे, लेकिन जानना चाहता हूँ कि वह speed असल में कहाँ फर्क डालती है
      हम Zod का इस्तेमाल सिर्फ form validation के लिए करते हैं, इसलिए लगता है “यह क्यों मायने रखता है?” क्या लोग high-throughput API input messages जैसी चीज़ें validate करते हैं, जहाँ performance अधिक महत्वपूर्ण हो जाती है?
    • जानना चाहता हूँ कि आपने TypeBox की जगह ArkType क्यों चुना
    • दिलचस्प है कि research करते समय मैंने उस tool को देखा ही नहीं था। मैं भी खास तौर पर TypeScript उपयोग-अनुभव देख रहा था
      फिर भी शायद मैं Zod से migrate नहीं करूँगा
    • ArkType लिखना एक बुरा सपना है, और Zod लिखना अच्छा लगता है

  • Zod team को नए release की बधाई। बहुत negative लगने का जोखिम उठाते हुए भी, migration guide में लिखे breaking changes की संख्या देखकर डर लगता है
    अगर कोई project Zod पर बहुत निर्भर है, तो यह developer focus और समय की बहुत मांग करने वाला भारी काम लग रहा है। काम पर 4–5 साल पुराने कुछ frontend projects maintain किए हैं, इसलिए यह खास तौर पर समझ आता है
    बड़े React projects आमतौर पर बहुत सारी libraries पर निर्भर होते हैं, और जब हर library बड़ा बदलाव लेकर आती है, ऊपर से docs भी कम हों, तो चीज़ें तुरंत overwhelming हो जाती हैं। JavaScript के साथ काम करते समय यह मेरी सबसे नापसंद चीज़ों में से एक है, और सब कुछ sync में रखकर smoothly चलाते रहना एक कभी न खत्म होने वाली चढ़ाई जैसा लगता है

    • पूरी तरह सहमत। हम कुछ बड़े Next.js apps चला रहे हैं, और पिछले 1 साल में हमें Next.js 14 → 15 के बड़े cache changes, Next.js pages → app router, React 18 → 19, Eslint 8 → 9, Tailwind 3 → 4 से गुजरना पड़ा
      सच कहूँ तो यह nightmare था, और लगा कि काश इसे Django में बनाया होता। उम्मीद के उलट Tailwind 3 → 4 migration सबसे दर्दनाक चीज़ों में से एक निकला
    • इसलिए उन्होंने अलग mini edition के साथ dual offering का तरीका चुना है। package manager को छेड़े बिना gradual migration करना आसान है
      जिन users को mini edition में रुचि नहीं है, उन्हें उस हिस्से की चिंता करने की ज़रूरत नहीं। लेकिन mini edition के tree-shaking benefits इतने बड़े हैं कि वे alternative development को बढ़ावा दे रहे थे, और Zod को इसे अपनाना था या पीछे छूटना था
    • बस LLM इस्तेमाल कर लो

  • production में हजारों users वाला SaaS खुद चलाने वाले full-stack developer के रूप में, कभी-कभी अच्छा लगता है यह महसूस करके कि SPA न बनाने और JS frontend framework न इस्तेमाल करने के कारण कितनी समस्याएँ हैं जिनके बारे में मुझे पता ही नहीं
    Zod/ArkType जैसी चीज़ की ज़रूरत के बारे में मैंने कभी सोचा भी नहीं, पहली बार सुना है और कभी इस्तेमाल भी नहीं करूँगा
    SPA बनाने में जितना effort, complexity और tooling लगता है, वह हैरान करने वाला है। SPA न बनाने का फैसला करें तो समस्याओं का एक पूरा वर्ग बस मौजूद ही नहीं रहता। इसके बजाय browser को उसी तरह इस्तेमाल करते हैं जैसे वह मूल रूप से design किया गया था—full page reloads और backend development पर focus—और कभी-कभी Laravel Livewire जैसे backend-only framework से थोड़ी reactivity जोड़ देते हैं
    access control से लेकर validation और state management तक सब कुछ सरल है। app तेज़, responsive, modern, SEO-friendly है, और production में हजारों लोगों को serve कर रहा है

    • 5 से अधिक teams के साथ काम करने वाले दो बड़े projects में हमने Zod और Protobuf का इस्तेमाल किया ताकि schema evolution ठीक से हो सके। हल्के frontend में भी backend पर schema validate करने के लिए कुछ इस्तेमाल करना मायने रखता है
      आखिर कहीं न कहीं schema होता ही है। वह database system में define हो सकता है, या ORM model में define हो सकता है। लेकिन बड़े projects में schema को database system या ORM में रखने से बहुत कठिन समस्याएँ पैदा हो सकती हैं, इसलिए हम Zod और Protobuf इस्तेमाल करते हैं। मुझे लगता है Protobuf को भी Zod या किसी समान चीज़ से पूरी तरह replace किया जा सकता है
      UK Post Office scandal में Horizon नाम का IT system शामिल था: https://en.wikipedia.org/wiki/British_Post_Office_scandal
      details पढ़ने पर लगा कि Zod जैसी schema validation होती तो शायद इस scandal को रोकने में मदद मिल सकती थी। class action court documents के technical appendix में भी schema के इस्तेमाल की अनुपस्थिति का ज़िक्र है: https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office...
    • Zod का SPA से संबंध नहीं है और यह केवल frontend tool भी नहीं है। क्या आप code में input validation नहीं करते?
    • आँखें बंद कर लेने से कभी-कभी समस्याओं का पूरा वर्ग मौजूद नहीं रह जाता
    • जानना चाहूँगा कि server-side validation कैसे करते हैं
      अभी तो ऐसा लग रहा है जैसे बहुत सारे defensive if statements लिखते हैं। उससे भी बुरा, शायद सिर्फ HTML client-side form validation पर निर्भर करते हों
    • हमारे पास data pipeline के हिस्से के रूप में इस्तेमाल होने वाली backend-only Zod schemas बहुत बड़ी संख्या में हैं। इसलिए यह ऐसा tool नहीं लगता जो सिर्फ SPA problem solve करने के लिए मौजूद हो

  • मैं विशेषज्ञ नहीं हूँ, इसलिए सावधानी से कह रहा हूँ, लेकिन मुझे लगा कि JSON Schema schema-based है, इसलिए TypeScript के अलावा दूसरी भाषाओं में भी validator implement किया जा सकता है; इस लिहाज से यह अच्छा विकल्प हो सकता है
    https://ajv.js.org ऐसी JSON Schema libraries में से एक है। Zod की तुलना में यह कैसा है, यह जानने की उत्सुकता है

    • Zod सिर्फ JSON validation के लिए tool नहीं है। यह उन objects को validate कर सकता है जिन्हें conversion के बिना JSON में represent नहीं किया जा सकता, जैसे date या class instance वगैरह
      चाहें तो इसे JSON converter की तरह भी इस्तेमाल कर सकते हैं। उदाहरण के लिए, ऐसी schema लिख सकते हैं जो string ले, verify करे कि वह ISO date string है या नहीं, और Date object output करे
    • Zod 4, Zod schema को JSON Schema में convert करने की सुविधा natively support करता है। पहले भी third-party libraries से यह संभव था
      अहम फर्क preprocessing और refine है। Zod में validation से पहले callback दिया जा सकता है, जो बहुत उपयोगी है लेकिन JSON में represent नहीं किया जा सकता। मसलन, date validation से पहले MM/DD/YYYY को DD/MM/YYYY में बदलना उम्मीद से ज्यादा बार काम आता है
    • ऐसे मामलों में JSON Schema अच्छा विकल्प है, और TypeBox इसे generate करने का ठीक-ठाक तरीका है
      validation के लिए AJV इस्तेमाल कर सकते हैं या TypeBox का अपना schema validation system। दूसरा काफी तेज़ है, लेकिन सिर्फ synchronous support करता है; AJV में database check जैसी asynchronous validation options हैं
    • भाषाओं के बीच validation के लिए JSON Schema सही है। इसे OpenAPI से wrap कर दें, तो अच्छे API docs भी मुफ्त में मिल जाते हैं

  • इस topic के आसपास की negative प्रतिक्रिया चौंकाने वाली है
    मैंने Zod v4 के शुरुआती version को test किया था और नया API पसंद आया था, लेकिन migration path कैसा होगा, इसे लेकर बहुत चिंतित था। मैं तो इसे बिल्कुल नए package name से release करने का सुझाव देने की सोच रहा था
    लेकिन author का approach समझदारी भरा है। यह मेरे जैसे लोगों को v4 तुरंत अपनाने देता है, बिना सभी dependencies के update होने का इंतज़ार किए

    • यह अच्छा रास्ता है। validation जैसी चीज़ों में all-or-nothing style migration संभालने का कोई तरीका नहीं है

  • मैंने अभी-अभी एक नए project में Zod adopt करना शुरू किया है, और इससे बेहतर timing नहीं हो सकती थी
    अभी जो दिख रहा है उसके आधार पर, v4 पर जाने के लिए सचमुच बहुत कुछ बदलना पड़ता