Zod 4 रिलीज़

 (zod.dev)
1 पॉइंट द्वारा GN⁺ 2025-05-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • schema declaration और validation library Zod का version 4 रिलीज़ हो गया है। इसमें बड़े performance improvements और लंबे समय से मांगे जा रहे features के साथ stable version जारी किया गया है
  • speed और bundle size में बड़े सुधार किए गए हैं, और नया mini version (v4-mini) bundle size को काफी कम करता है
  • नया metadata registry, JSON Schema conversion, और recursive type inference feature जोड़े गए हैं
  • error message customization और multilingual locale system जैसी सुविधाओं से developer experience बेहतर हुआ है
  • भविष्य में library building के लिए उपयोगी core subpackage की शुरुआत से extensibility और बढ़ी है

Zod 4 का परिचय

मुख्य रिलीज़ की जानकारी

  • 1 साल के सक्रिय विकास के बाद Zod 4 stable version के रूप में जारी किया गया है
  • इसका विकास Clerk की OSS Fellowship सहायता से किया गया
  • अभी इसे Zod 3 के साथ parallel में distribute किया जा रहा है, जिससे Zod 4 की ओर gradual migration आसान हो जाता है
  • कुछ breaking changes की विस्तृत जानकारी Migration guide में देखी जा सकती है

विकास की पृष्ठभूमि

  • 2021 में जारी Zod 3 की तुलना में Zod 4 के GitHub stars और weekly downloads में exponential growth हुई है
  • Zod 4 कहीं अधिक तेज, slim है, और TypeScript compiler efficiency भी बेहतर हुई है
  • लंबे समय से मांगे गए 9 प्रमुख issues को हल किया गया है

benchmark और performance

  • speed improvement:
    • string parsing: 14.71 गुना तेज परिणाम
    • array parsing: 7.43 गुना तेज
    • object parsing (safeParse): 6.5 गुना तेज
  • repo में सीधे benchmark चलाने के लिए script दी गई है
  • बेहतर generic structure की वजह से .extend(), .omit() जैसी method chaining के दौरान compile performance 10 गुना बेहतर हुई है
  • बड़े schema और codebase में TypeScript compile speed में बड़ा सुधार हुआ है

bundle size और Zod Mini

  • base bundle size में 57% की कमी आई है, इसलिए v4, v3 की तुलना में 2.3 गुना छोटा है
  • zod/v4-mini function-based tree-shakeable API देता है, जो bundle size को 85% तक कम करता है
  • core और v4-mini के API अंतर आधिकारिक docs में विस्तार से दिए गए हैं
  • structure को इस तरह डिज़ाइन किया गया है कि bundler unused methods को आसानी से हटा सके

metadata registry और JSON Schema support

  • schema में typed metadata को strong typing के साथ register और manage किया जा सकता है
  • global registry(z.globalRegistry) में JSON Schema-compatible metadata processing और automatic inclusion की सुविधा है
  • .meta(), .describe() के जरिए schema documentation आसान हो जाती है
  • .toJSONSchema() से schema को JSON Schema format में convert किया जा सकता है, और metadata अपने आप reflect होता है

recursive type automatic inference

  • recursive object types और mutually recursive types को बिना अलग type casting के स्वाभाविक तरीके से define और infer किया जा सकता है
  • पुराने Zod 3 pattern की तुलना में usability काफी बेहतर हुई है
  • recursive और mutually recursive types में भी सभी schema methods का उपयोग संभव है

file type और validation features

  • नए file() type से File instances को validate किया जा सकता है
  • file size (min, max) और MIME type सहित कई file constraints की validation उपलब्ध है

error message और locale system

  • global locale API(z.locales) के जरिए error messages के multilingual support की सुविधा मिलती है
  • आधिकारिक z.prettifyError function user-friendly error formatting देता है

format functions और template literals

  • मौजूदा string formats(email आदि) को top-level functions में promote किया गया है, जिससे readability और tree shaking बेहतर होती है
  • कई तरह के email regex विकल्प दिए गए हैं, ताकि अलग-अलग validation requirements पूरी की जा सकें
  • template literal type support: type system में व्यक्त किए जा सकने वाले string patterns और जटिल combinations को आसानी से implement किया जा सकता है

नए number और bigint formats

  • fixed-width integer और floating-point types (int32, uint64 आदि) का समर्थन
  • safe range के भीतर अपने आप minimum/maximum constraints जुड़े हुए schema बनाए जा सकते हैं

z.stringbool का परिचय

  • string-based boolean parsing(yes, no आदि) संभव है, और environment variable style parsing भी supported है
  • truthy/falsy values को customize किया जा सकता है

error customization API का एकीकरण

  • एकीकृत error parameter के जरिए error messages और handling logic की संरचना को व्यवस्थित किया गया है
  • मौजूदा कई error-related APIs (message, invalid_type_error, errorMap) अब deprecated हैं

अन्य मुख्य सुधार

  • discriminated unions अब विभिन्न schema, nesting और combinations को support करते हैं
  • .literal() अब एक साथ कई values स्वीकार कर सकता है
  • .refine() जैसी custom validations अब और अधिक सहज रूप से integrate की गई हैं
  • transform-related .overwrite() से transformed type बदले बिना post-processing संभव है

library extensibility और नया core

  • zod/v4/core के रूप में core functionality को अलग subpackage में विभाजित किया गया है, जिससे विभिन्न libraries और platforms में integration/extension संभव है
  • library authors के लिए guide docs और extension examples भी दिए गए हैं

समापन

  • Zod 4 ने type safety, performance, extensibility, और developer experience सभी में बड़े सुधार किए हैं और यह data validation library के रूप में और मजबूत हुआ है
  • आगे अतिरिक्त design posts और updates की घोषणा की गई है
  • मौजूदा users और library authors दोनों के लिए व्यापक support तैयार किया गया है

बेहतर parsing अनुभव की शुभकामनाएँ
— Colin McDonnell @colinhacks

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

1 टिप्पणियां

 
GN⁺ 2025-05-20
Hacker News प्रतिक्रियाएँ

  • लेखक ने अपनी राय साझा करने के अनुरोध के साथ versioning के तरीके का विस्तार से वर्णन किया और इस बात पर ज़ोर दिया कि npm, Zod जैसी स्थिति को संभालने के लिए उपयुक्त नहीं है। उन्होंने यह भी कहा कि बहुत-सी libraries Zod के interfaces/classes को सीधे import करके इस्तेमाल करती हैं। अगर Zod का major version बदलता है, तो इन सभी libraries को एक साथ उसके अनुसार बदलना पड़ेगा और version explosion जैसी स्थिति आ सकती है। Go की तरह breaking changes के लिए नया subpath जोड़ने का तरीका अपनाने की बात कही गई, और समझाया गया कि TypeScript environment में सिर्फ zod@^3.25.0 के साथ "zod/v3" और "zod/v4" दोनों को एक साथ support किया जा सकता है। इससे end users को gradual upgrade path मिलता है。

    • Zod में योगदान के लिए धन्यवाद दिया गया, खासकर tsc performance improvements और discriminated unions में सुधार को लेकर उत्साह जताया गया। Versioning strategy पूरी तरह समझ में आती है, लेकिन ऐसे users के लिए जिन्हें transitive dependency conflicts की चिंता नहीं है, 4.0.0 package के रूप में एक सीधा विकल्प देना भी अच्छा हो सकता था। "zod/v4" पर imports बदलने से code में noise बढ़ने, IDE auto-import conflicts और extra inconvenience होने की आशंका जताई गई। फिर भी इसे कुल मिलाकर बहुत promising upgrade कहा गया और धन्यवाद दिया गया।

    • मोबाइल पर लेख देखते समय कुछ छूट गया हो तो क्षमा मांगी गई, और पूछा गया कि .optional() से जुड़ी सबसे बड़ी असुविधा इस बार top 10 issues में शामिल fixes में हल हुई है या नहीं। यह भी कहा गया कि Zod इतना अच्छा है कि असुविधा के बावजूद उसका उपयोग जारी है, और शानदार library के लिए आभार जताया गया।

    • Zod के नए version में बहुत-सा manual hacking code हटाया जा सकेगा, इसके लिए धन्यवाद दिया गया। Typo कम करने के लिए zod-key-parser का उपयोग करने की बात कही गई और पूछा गया कि ऐसी functionality library में built-in क्यों नहीं है — क्या उसे out of scope माना गया, या अभी तक implement नहीं किया गया। इससे जुड़ी open discussions भी साझा की गईं।

    • इस बात पर ज़ोर दिया गया कि short-term pain को minimize करने का तरीका कई बार सबसे अच्छा होता है, और Python 2/3 migration chaos का उदाहरण याद दिलाया गया।

    • Recursive types और discriminated union patterns को एक साथ इस्तेमाल करने, जैसे XML को JSON के भीतर रखना, में काफ़ी कठिनाई हुई थी। उम्मीद जताई गई कि इस update से स्थिति काफ़ी बेहतर होगी।

  • zod/v4-mini import को लेकर संदेह जताया गया। अनुमान लगाया गया कि इससे उल्टा bundle size बढ़ सकता है। Documentation में zod/v4 को ज़्यादातर cases में recommended बताया गया है, इसलिए app developers zod/v4 इस्तेमाल करेंगे, लेकिन अगर library authors bundle size कम करने के लिए zod/v4-mini भी जोड़ें, तो दोनों bundle में शामिल होकर duplication कर सकते हैं। पूछा गया कि अगर zod/v4 वास्तव में zod/v4-mini का wrapper हो, तो क्या यह समस्या कम हो सकती है।

  • Zod 4 की migration आसान बनाने के लिए v3 और v4 को zod@3.25 में साथ देने का तरीका अपनाया गया। इसकी आलोचना करते हुए कहा गया कि npm dependency management की सीमाओं के कारण v4 को v3 जैसा दिखाना पड़ा, और npm के peer dependencies system को inefficient बताया गया।

    • लेखक ने फिर से Golang-style subpath versioning strategy समझाई। उन्होंने कहा कि npm की प्रकृति के कारण इसे Zod ecosystem में लाना कठिन है, लेकिन v3 और v4 को साथ support करने और gradual migration देने का यह एक बड़ा फ़ायदा है।

    • इस बात से पूरी सहमति नहीं जताई गई कि peer dependencies के टूटे होने की वजह से v4 को v3 के रूप में छिपाया गया। ज़ोर दिया गया कि यह gradual migration के लिए एक व्यावहारिक तरीका है, जिसमें एक-एक कर zod/v4 पर स्विच करके अंततः पूरी तरह v4 पर जाया जा सकता है।

    • कई लोग इसकी आलोचना कर रहे हैं, लेकिन कहा गया कि यह npm की कोई बुनियादी कमी कम और बड़े breaking changes वाली library को धीरे-धीरे बदलने देने वाला एक pragmatic decision ज़्यादा है।

    • लंबे समय से सिर्फ npm इस्तेमाल करने के कारण पक्षपात हो सकता है, लेकिन यह पूछा गया कि v3 से v4 पर एकदम बड़े jump की बजाय gradual support देने का इससे बेहतर तरीका और क्या हो सकता था।

    • zod 4 beta में पहले ही बड़े improvements का अनुभव होने के बावजूद, बड़े codebase में module resolution settings की कठिनाइयों के कारण ठीक से upgrade नहीं कर पाने की बात कही गई। इच्छा जताई गई कि legacy layer के बिना सिर्फ major version package के रूप में भी release मिलता। लेखक की version explosion से बचने वाली व्याख्या साझा की गई, लेकिन साथ ही यह निजी राय भी दी गई कि v3 support parallel रखने से shockwave कम हो सकती है।

  • पूछा गया कि जब server से लौटने वाले types हर endpoint पर अलग हों, या कुछ fields anonymous user की तरह null हो सकती हों, तो ऐसी complex server responses को किस type model से handle करना चाहिए। normalizeUser/normalizePost जैसी कई functions बनाते-बनाते maintenance मुश्किल होने की बात कही गई और practical experience मांगा गया।

    • समाधान के रूप में discriminated union का उदाहरण दिया गया। Common schema parts को object के रूप में define करके, specific situations के लिए उसे extend करने का तरीका समझाया गया। यह भी कहा गया कि बहुत विविध cases में complexity तो रहेगी, लेकिन schema validator से कम से कम चीजें structured रह सकती हैं।

    • आदर्श रूप से User type structure का एक single source, जैसे discriminated union, तय करना सबसे अच्छा बताया गया। Python backend मानते हुए कई Pydantic models + union और OpenAPI/GraphQL code generation से TypeScript client types बनाने का सुझाव दिया गया।

    • कहा गया कि अगर actual use case पता हो तो बेहतर जवाब दिया जा सकता है, लेकिन union type में discriminator property, जैसे "user_type", जोड़ने से individual fields तक access आसान हो जाता है और type system context के अनुसार सही properties पहचान सकता है।

    • सलाह दी गई कि server को ही types export करने चाहिए। Client पर अलग से types दोबारा लिखना inefficient है। Python backend के लिए Pydantic से OpenAPI spec auto-generate करके TypeScript client types generate करने का तरीका बताया गया।

    • यह भी कहा गया कि GraphQL ऐसे cases के लिए अच्छा fit है। TypeScript GraphQL libraries query results के shape को automatically infer कर सकती हैं और selected fields के हिसाब से response types dynamically बनते हैं।

  • कहा गया कि Zod 4 में improvements के बावजूद ArkType अभी भी काफ़ी तेज़ है। पुराने libraries में backward compatibility और syntax बनाए रखने की वजह से performance limits रहती हैं। निजी project analysis के आधार पर ArkType चुनने की वजह performance और TypeScript usability बताई गई।

    • ArkType के speed metrics देखे गए, लेकिन पूछा गया कि वह speed practical usage में क्या फ़र्क लाती है। Form validation जैसे सामान्य scenarios में उसका प्रभाव कम लगता है, इसलिए जिज्ञासा जताई गई कि क्या यह ultra-fast API input validation जैसे performance-sensitive cases में इस्तेमाल होता है।

    • कहा गया कि ArkType research में शामिल नहीं था, लेकिन TypeScript usability को देखते हुए उसकी तलाश की गई थी। फिर भी Zod से migrate करने की योजना नहीं है।

    • ArkType का उपयोग अनुभव बहुत कठिन लगा, जबकि Zod अधिक usable लगा, इसलिए Zod को प्राथमिकता देने की बात कही गई।

    • पूछा गया कि TypeBox की बजाय ArkType चुनने की खास वजह क्या थी।

  • Zod team को नए release पर बधाई दी गई, लेकिन migration guide में breaking changes की संख्या देखकर चिंता जताई गई कि बड़े Zod-dependent projects के लिए यह भारी और manage करना कठिन होगा। पुराने frontend projects maintain करने के अनुभव के आधार पर कहा गया कि हर library में बड़े changes और documentation gaps बहुत दिखते हैं, जो JS ecosystem की मौजूदा दिशा पर कुछ निराशा पैदा करते हैं।

    • कई बड़े Next.js apps चलाने का अनुभव साझा किया गया, जहाँ पिछले एक साल में Next.js 14→15, Next.js pages→app router, React 18→19, Eslint 8→9, Tailwind 3→4 जैसे बड़े और कठिन बदलावों से गुजरना पड़ा। इसे बेहद थकाने वाला बताया गया, और मज़ाक में कहा गया कि काश इसे Django में बनाया होता। खास तौर पर Tailwind 3→4 migration को उम्मीद से ज़्यादा दर्दनाक बताया गया।

    • समझाया गया कि ऐसी समस्याओं को कम करने के लिए mini edition को साथ देने की strategy अपनाई गई। इससे gradual transition आसान होता है, और tree-shaking optimization के लिहाज़ से mini लाना alternatives के सामने टिके रहने के लिए ज़रूरी था।

    • LLM जैसे tools की मदद से migration आसानी से की जा सकती है, ऐसा सुझाव दिया गया।

  • कहा गया कि Zod मौजूदा alternatives की तुलना में बहुत बेहतर है, लेकिन web development में एक ही data structure को कई तरीकों से describe करना अब भी वास्तविकता है। JS input validation, Swagger के जरिए API spec, server और client पर अलग-अलग definitions — यह सब बहुत repetitive और tedious लगता है।

    • TypeScript के सिर्फ static checking tool बने रहने पर कुछ निराशा जताई गई। Runtime checks की मांग नहीं की गई, लेकिन इच्छा जताई गई कि classes/functions/objects की type information को बाहर आसानी से इस्तेमाल किया जा सके। अभी कई tools को अपने-अपने models और builders define करने पड़ते हैं, इसलिए duplication unavoidable है। Standard Schema project जैसे standardization प्रयासों का ज़िक्र किया गया, जो प्रमुख validation libraries के साथ integrate होने की दिशा में दिखता है, लेकिन API spec और ORM तक विस्तार अभी शुरुआती चरण में है।

    • कहा गया कि ऐसे tools का मुख्य लाभ यह है कि आप एक बार define करके type safety को पूरे app में propagate कर सकते हैं, और Zod schema को single source of truth की तरह इस्तेमाल किया जा सकता है।

    • यह भी जोड़ा गया कि इस तरह की जटिलता से परेशान कई लोग, TypeScript (Zod सहित) से सब कुछ unify करने के विचार को भी पसंद नहीं करते।

    • कहा गया कि सभी APIs और systems हमेशा बदलाव और experimentation की स्थिति में रहते हैं। Complex layers का बढ़ना downside ज़रूर है, लेकिन जब लक्ष्य सिर्फ इतना हो कि “project में चीज़ें काम करती रहें”, तो यह आख़िरकार और ज़्यादा काम पैदा करता है।

    • कुल मिलाकर, trpc जैसी end-to-end type safety अपनाई जा सकती है, लेकिन उसके लिए frontend और backend दोनों को TypeScript में रखना पड़ता है, और web के बाहर mobile जैसे platforms के साथ काम करना कठिन हो सकता है — इसे practical limitation बताया गया।

  • कहा गया कि विशेषज्ञ नहीं हैं, लेकिन schema-based JSON-Schema, TypeScript के बाहर दूसरी languages में भी validators implement करने की सुविधा के कारण एक अच्छा विकल्प हो सकता है। ajv.js.org जैसी library का उदाहरण देते हुए Zod से तुलना पूछी गई।

    • जवाब में कहा गया कि Zod सिर्फ JSON-like data ही नहीं, बल्कि पूरे JS objects जैसे dates, class instances आदि पर भी validation कर सकता है, जिन्हें JSON में express नहीं किया जा सकता। इसे JSON transformation process में भी इस्तेमाल किया जा सकता है, और string-based schemas लिखकर ISO date string को Date object में validate/convert करने जैसे काम किए जा सकते हैं।

    • यह भी बताया गया कि Zod 4 अब Zod schema को JSON-Schema में convert करने का support देता है, जबकि पहले इसके लिए external library चाहिए होती थी। Zod की बड़ी खासियत preprocess/refine जैसी features हैं, जिनसे validation से पहले callbacks जोड़े जा सकते हैं — जैसे MM/DD/YYYY को DD/MM/YYYY में बदलकर validate करना। ज़ोर दिया गया कि JSON-Schema में इस तरह की flexibility नहीं होती।

    • कहा गया कि JSON-Schema भी एक अच्छा विकल्प है, और इस स्थिति में TypeBox generation के लिए उपयुक्त है। ajv इस्तेमाल किया जा सकता है, या उसका अपना validation system भी। खुद का validation तेज़ हो सकता है, लेकिन वह sync-only है, जबकि ajv async validation भी कर सकता है, इसलिए deep validation scenarios में वह फ़ायदेमंद है।

    • कई languages में उपयोग करना हो तो JSON-Schema सबसे universal विकल्प है, और अगर उसे OpenAPI में wrap किया जाए तो API documentation भी अपने-आप generate की जा सकती है।

  • कहा गया कि Zod को नए project में अभी-अभी अपनाना शुरू किया था, और यह release timing बिल्कुल सही रही। अगर योजना के अनुसार बाद में v4 migration करनी पड़ती, तो काफ़ी बदलाव करने पड़ते, इसलिए timing को बहुत lucky बताया गया।

  • अपेक्षा से ज़्यादा negative reactions देखकर हैरानी जताई गई। v4 के शुरुआती versions को test करते समय नया API पसंद आया था, लेकिन migration path को लेकर चिंता थी, यहाँ तक कि अलग package name से release करने का विचार भी आया था। लेकिन लेखक के approach को बहुत शानदार बताया गया, क्योंकि इससे dependency updates का इंतज़ार किए बिना तुरंत v4 अपनाया जा सकता है।

    • यह भी कहा गया कि validation जैसे domain में सब कुछ एक साथ migrate कर पाना संभव नहीं होता, इसलिए मौजूदा approach को व्यवहारिक रूप से सबसे अच्छा माना गया।