Zod 4 sürümü yayınlandı

 (zod.dev)
1 puan yazan GN⁺ 2025-05-20 | 1 yorum | WhatsApp'ta paylaş
  • Zod 4, 1 yıllık geliştirmenin ardından kararlı sürüm olarak yayınlandı; Zod 3'ün tasarım sınırlarını giderip performans, bundle boyutu ve TypeScript derleme verimliliği alanlarında büyük iyileştirmeler getiriyor
  • Mayıs 2021'de çıkan Zod 3, GitHub'da 2.700 yıldız ve haftalık 600 bin indirmeden bugün 37.8k yıldız ve haftalık 31 milyon indirme ölçeğine ulaştı; 24 küçük sürümün ardından temel iyileştirmeler için geriye dönük uyumluluğu bozan değişiklikler gerekli hale geldi
  • Benchmark'larda string parsing 14 kat, dizi parsing 7 kat, nesne parsing ise 6.5 kat hızlandı; tsc type instantiation sayısı da basit bir örnekte 25.000'in üzerindeyken yaklaşık 175'e düştü
  • Çekirdek bundle boyutu gzip bazında Zod 3'te 12.47kb iken Zod 4'ün normal sürümünde 5.36kb'ye indi; tree-shaking yapılabilen fonksiyonel API Zod Mini ise 1.88kb seviyesine kadar küçüldü
  • Yeni özellikler arasında JSON Schema dönüşümü, metadata registry, recursive object type inference, uluslararasılaştırma, hata pretty-printing, template literal type, z.stringbool(), birleşik error parametresi ve geliştirilmiş z.discriminatedUnion() yer alıyor

Zod 4 neden yeni bir major sürüm oldu?

  • Zod 4, 1 yıllık yoğun geliştirme sürecinin ardından kararlı sürüme ulaştı ve daha hızlı, daha küçük, tsc açısından daha verimli bir temel üzerinde uzun süredir istenen özellikleri hayata geçiriyor
  • Zod v3.0, Mayıs 2021'de yayınlandı; o dönemde GitHub yıldız sayısı 2.700, haftalık indirme sayısı ise 600 bindi
  • Bugün Zod, GitHub'da 37.8k yıldız ve haftalık 31 milyon indirme seviyesine ulaştı
    • Beta sürümünün çıkmasından 6 hafta önce haftalık indirme sayısı 23 milyondu
  • 24 küçük sürüm boyunca Zod 3 kod tabanı sınırına ulaştı ve en çok talep edilen özellikler ile iyileştirmeler için geriye dönük uyumluluğu bozan değişiklikler gerekli hale geldi
  • Zod 4, en çok oy alan herkese açık ilk 10 issue'nun 9'unu kapattı

Parsing performansı ve TypeScript derleme verimliliği

  • Zod 4, depoda doğrudan çalıştırılabilen benchmark'lar sunuyor
  • Parsing performansındaki iyileştirmeler:
    • String parsing: 14 kat daha hızlı
    • Dizi parsing: 7 kat daha hızlı
    • Nesne parsing: 6.5 kat daha hızlı
  • Nesne parsing benchmark'ı, Moltar validation library benchmark çalıştırılarak ölçüldü
  • tsc --extendedDiagnostics baz alındığında, basit bir dosyanın derlenmesinde type instantiation sayısı büyük ölçüde azaldı
    • "zod/v3" kullanıldığında 25.000'in üzerinde
    • "zod/v4" kullanıldığında yaklaşık 175
  • Zod 4, ZodObject ve diğer schema sınıflarının generic yapısını yeniden tasarlayıp sadeleştirerek instantiation patlamasını önlüyor
  • .extend() ve .omit() zincirlerinin tekrarlandığı bir kalıp, Zod 3'te derleme için 4000ms gerektiriyordu ve ek .extend() çağrıları "Possibly infinite" hatasına yol açabiliyordu
  • Aynı kalıp Zod 4'te 400ms içinde derlenerek 10 kat hızlanıyor
  • Gelecekte tsgo derleyicisiyle birlikte kullanıldığında, Zod 4'ün editör performansı daha büyük schema'lara ve kod tabanlarına da ölçeklenebilir

Bundle boyutu ve Zod Mini

  • Basit bir z.boolean() doğrulama betiği rollup ile bundle'lanarak çekirdek bundle boyutu karşılaştırıldı
  • gzip bazında çekirdek bundle boyutu:
    • Zod 3: 12.47kb
    • Zod 4 normal sürüm: 5.36kb
  • Zod 4 normal sürümünün çekirdek bundle'ı, Zod 3'e göre yaklaşık %57 daha küçük ve 2.3 kat daha az yer kaplıyor
  • Zod'un yöntem odaklı API'si doğası gereği tree-shaking için zorlayıcı; basit bir z.boolean() betiği bile .optional() ve .array() gibi kullanılmayan yöntem uygulamalarını da beraberinde getiriyor
  • Zod Mini, zod ile bire bir eşleşen fonksiyonel ve tree-shaking yapılabilen bir API sunuyor
    • Zod'un yöntem kullandığı yerlerde Zod Mini genellikle wrapper fonksiyonlar kullanıyor
    • Parsing yöntemleri Zod ve Zod Mini'de aynı
    • Genel amaçlı .check() yöntemiyle refinement eklenebiliyor
  • Normal Zod, çoğu kullanım senaryosu için önerilmeye devam ediyor; bundle boyutu kısıtları olağan dışı derecede sıkı olan projeler Zod Mini'yi değerlendirebilir
  • zod/mini kullanıldığında gzip bundle boyutu 1.88kb
    • Zod 3'e göre %85, yani 6.6 kat daha küçük
    • Karşılaştırma tablosu: Zod 3 12.47kb, Zod 4 normal 5.36kb, Zod 4 Mini 1.88kb
  • Ayrıntılar zod/mini belgelerinde yer alıyor

Metadata ve JSON Schema

  • Zod 4, schema'lara strongly typed metadata eklemek için yeni bir sistem sunuyor
  • Metadata, schema'nın içinde değil; schema ile typed metadata'yı ilişkilendiren bir schema registry içinde tutuluyor
  • z.registry() ile registry oluşturulabiliyor ve schema'nın .register() yöntemiyle kolay kayıt yapılabiliyor
  • Zod, yaygın JSON Schema uyumlu metadata'yı kabul eden genel registry z.globalRegistry'yi dışa aktarıyor
  • .meta() yöntemi, schema'yı z.globalRegistry'ye kolayca ekliyor
  • Zod 3 uyumluluğu için .describe() korunuyor, ancak Zod 4'te önerilen yöntem .meta()
  • Zod 4, z.toJSONSchema() aracılığıyla birinci taraf JSON Schema dönüşümü sunuyor
  • z.globalRegistry içindeki metadata, JSON Schema çıktısına otomatik olarak ekleniyor
  • Üretilen JSON Schema'nın özelleştirilmesiyle ilgili bilgiler JSON Schema docs içinde bulunuyor

Yeni schema ifadeleri ve type özellikleri

  • Zod 4, recursive object type'ları doğru şekilde infer edebiliyor
    • Recursive type'lar ve karşılıklı recursive type'lar ifade edilebiliyor
    • Zod 3'teki recursive type kalıplarının aksine type cast gerekmiyor
    • Ortaya çıkan schema, normal bir ZodObject instance'ı olduğu için tüm yöntemler kullanılabiliyor
  • File instance doğrulaması için File schema eklendi
  • z.templateLiteral(), TypeScript'in template literal type'larını ifade ediyor
    • String'e dönüştürülebilen Zod schema type'ları iç regex'lerini saklıyor
    • Hedefler arasında string, z.email() gibi string formatları, sayı, boolean, bigint, enum, literal, undefined/optional, null/nullable ve diğer template literal'lar yer alıyor
    • z.templateLiteral oluşturucusu bunları tek bir super-regex içinde birleştiriyor
    • z.email() gibi string formatları düzgün şekilde zorunlu kılınıyor, ancak custom refinement zorunlu kılınmıyor
    • Ayrıntılar template literal docs sayfasında bulunuyor
  • Sabit genişlikli tam sayı ve kayan noktalı sayı type'larını ifade eden yeni sayı formatları eklendi
    • Bunlar, uygun inclusive minimum/maximum kısıtları önceden eklenmiş ZodNumber instance'ları döndürüyor
  • JavaScript number ile güvenli şekilde ifade edilebilen aralığı aşan bigint sayı formatları da eklendi
    • Bunlar da uygun inclusive minimum/maximum kısıtları önceden eklenmiş ZodBigInt instance'ları döndürüyor
  • z.literal() artık isteğe bağlı olarak birden fazla değer alabiliyor

Hatalar, uluslararasılaştırma ve string formatları

  • Zod 4, hata mesajlarını birden fazla dile global olarak çevirmek için yeni locales API'sini sunuyor
  • Desteklenen locale'lerin tam listesi Customizing errors sayfasında yer alıyor ve desteklenen diller arttıkça güncelleniyor
  • Zod, ZodError nesnesini kullanıcı dostu biçimde string'e dönüştüren üst seviye z.prettifyError fonksiyonunu uyguluyor
    • Şu an biçimi yapılandırılamıyor
    • Gelecekte değişebilir
    • Hâlihazırda zod-validation-error kullanıyorsanız kullanmaya devam edebilirsiniz
  • Email dahil tüm string formatları z modülünün üst seviye fonksiyonlarına yükseltildi
    • Daha kısa ve tree-shaking için daha elverişli
    • z.string().email() gibi yöntem tabanlı karşılıklar kullanılmaya devam edebilir ancak deprecated durumdalar
    • Bir sonraki major sürümde kaldırılmaları planlanıyor
  • z.email() API'si custom regular expression desteği sunuyor
    • Tek bir canonical email regex'i yok; uygulamalar daha katı ya da daha esnek ölçütler seçebilir
    • Zod kolaylık sağlamak için birkaç yaygın regex'i dışa aktarıyor

Boolean dönüştürme ve hata özelleştirmesinin sadeleştirilmesi

  • Mevcut z.coerce.boolean(), falsy değerleri false, truthy değerleri true yapan basit bir API
    • false, undefined, null, 0, "", NaN gibi değerler false olur
    • Bu davranış diğer z.coerce API'leriyle uyumlu
  • Zod 4, env tarzı daha gelişmiş boolean coercion için z.stringbool() sunuyor
    • truthy ve falsy değerler özelleştirilebiliyor
    • Ayrıntılar z.stringbool() docs sayfasında bulunuyor
  • Zod 4'teki geriye dönük uyumluluğu bozan değişikliklerin çoğu hata özelleştirme API'siyle ilgili
  • Hata özelleştirmesi tek bir error parametresinde birleştirildi
    • message, error ile değiştirildi
    • message parametresi desteklenmeye devam ediyor ama deprecated durumda
    • invalid_type_error ve required_error, fonksiyon sözdizimindeki error ile değiştirildi
    • errorMap de fonksiyon sözdizimindeki error ile değiştirildi

Birleştirilebilirlik, refinement ve transform

  • z.discriminatedUnion() artık daha önce desteklenmeyen çeşitli schema type'larını destekliyor
    • Buna union ve pipe da dahil
    • Discriminated union, başka bir discriminated union'ın üyesi olabildiği için birleştirilebilir hale geliyor
  • Zod 3'te refinement, orijinal schema'yı saran ZodEffects sınıfında tutuluyordu
    • Bu yapı, .refine() ile .min() gibi diğer schema yöntemlerini birlikte kullanmayı zorlaştırıyordu
  • Zod 4'te refinement schema'nın içinde saklanıyor; böylece .refine() ve diğer schema yöntemleri doğal şekilde birlikte kullanılabiliyor
  • Yeni .overwrite() yöntemi, inferred type'ı değiştirmeyen transform'ları ifade ediyor
    • .transform() çıktısının type'ı runtime'da introspect edilemez ve transform fonksiyonu herhangi bir şey döndürebilen bir kara kutudur
    • Bu yüzden JSON Schema'ya güvenli biçimde dönüştürmenin bir yolu yoktur
    • .overwrite() orijinal sınıfın bir instance'ını döndürür
    • overwrite fonksiyonu refinement olarak saklanır ve inferred type'ı değiştirmez
  • Mevcut .trim(), .toLowerCase() ve .toUpperCase() artık .overwrite() kullanılarak yeniden uygulanıyor

Kütüphane yazarları için temel

  • Zod Mini'nin eklenmesiyle, Zod ve Zod Mini'nin paylaştığı çekirdek işlevleri içeren zod/v4/core alt paketi oluşturuldu
  • zod/v4/core, Zod'u basit bir kütüphaneden çıkarıp diğer kütüphanelerin içine gömülebilen hızlı bir doğrulama temeline dönüştürüyor
  • Bir schema kütüphanesi geliştiriyorsanız, Zod ve Zod Mini uygulamalarını referans alıp zod/v4/core üzerine inşa edebilirsiniz
  • Kütüphane yazarları için For library authors rehberi sunuluyor
    • Zod üzerine inşa ederken best practice'leri ele alıyor
    • Zod 3, Zod 4 ve Mini'yi aynı anda destekleme konusunda sık sorulan soruları yanıtlıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-20
Hacker News yorumları

  • Yazarıyım, istediğinizi sorun. Sürüm politikası konusunda bu yaklaşımın gerekçesini epey ayrıntılı yazdım: https://github.com/colinhacks/zod/issues/4371
    Sonuçta npm, Zod’un içinde bulunduğu durumu iyi yönetmek üzere tasarlanmamış. Onlarca-yüzlerce kütüphane Zod’un arayüzlerini/sınıflarını doğrudan içe aktarıp kendi public API’lerinde kullandığı için, Zod her major sürüm artırdığında bu kütüphanelerin de yeni major sürüm çıkarması gerekiyor
    Tek başına bakıldığında mantıklı, ama Zod’da herkes için acı verici bir sürüm çığı oluşabilir ve ekosistemin önemli bir kısmı sonsuza dek v3’e kilitlenecek gibi görünüyordu
    Bu yüzden Go’dakine benzer şekilde, paketin uyumluluğu bozan yeni bir sürüm çıkarması yerine yeni bir alt yol ekleme yolunu seçtik. TypeScript ekosisteminde bir kütüphane yalnızca zod@^3.25.0 peer dependency’si koyup "zod/v3" ve "zod/v4" üzerinden gerekenleri içe aktararak iki sürümü aynı anda destekleyebilir

    • Büyük kod tabanlarında tsc performans artışı özellikle sevindirici; discriminated union değişikliklerinin de şimdiye kadar eksik kalan belirli senaryolarda çok yardımcı olacağını düşünüyorum
      Ancak özel koşullar nedeniyle biraz tuhaf bir sürüm politikası seçilmesini anlasam da, transitif bağımlılıklardaki Zod sürüm çakışmalarını dert etmesi gerekmeyen ekipler açısından 4.0.0 paketi de olsaydı iyi olurdu
      Doğru anladıysam import’ları "zod/v4" olarak değiştirmek gerekiyor; bu çok gürültülü bir değişiklik ve IDE’nin 'zod' üzerinden otomatik import yapma sorununu lint kuralıyla yakalamak gerektiği için can sıkıcı olabilir
    • Bu yaklaşım çok makul. Önceki sürüm güvenlik güncellemelerinin de aynı kod tabanı sürümü içinde birlikte sunulabileceği anlamına geliyor
    • Mobilde olduğum için yazıda zaten var mı göremedim ama TypeScript’te .optional()’ı düzeltme işi en üstteki 9-10 issue’nun çözümüne dahil mi merak ediyorum: https://github.com/colinhacks/zod/issues/635
      Bu, Zod’da yaşadığım en büyük sıkıntıydı; ama Zod o kadar iyi ki yine de buna katlanıp kullanıyorum
    • Yeni özellikler sayesinde yerelde yaptığım birçok geçici hack’i kaldırabilecek gibiyim. Form adı yazım hatalarından kaçınmak için https://github.com/raflymln/zod-key-parser’ın kendi sürümümü kullanıyorum; böyle bir özelliğin doğrudan kütüphaneye girmemiş olması şaşırtıcıydı
      Bunu Zod’un kapsamı dışında mı görüyorsunuz, yoksa henüz uygulamaya zaman mı olmadı merak ediyorum. İlgili tartışma https://github.com/colinhacks/zod/discussions/2134 adresinde
    • Zod 4’ün en erken sürümünün 3.25.0 olduğu anlamına geliyorsa, bu biraz mantıksız geliyor
      Aylardır Zod alfa sürümünü kullanıyordum ve sadece package.json’ı düzelterek yükseltmek istiyordum; şimdi tüm git geçmişini kurcalamam gerekecek gibi görünüyor
      Projeyi büyük minnetle kullanıyorum ama bu geri bildirim özelinde, gereğinden fazla zorlaştırılmış gibi. 3.x ile birlikte 4.x de yayımlanamaz mıydı diye düşünüyorum

  • “Migrasyonu basitleştirmek için Zod 4’ü zod@3.25 sürümünün parçası olarak Zod 3 ile birlikte dağıtıp "/v4" alt yolundan içe aktartmak” ifadesi, npm bağımlılık yönetiminin tamamen karmakarışık olduğunun işareti gibi görünüyor
    Peer dependency’ler o kadar bozulmuş ki v4’ün v3’müş gibi davranması gereken bir duruma gelinmiş

    • Yazarıyım. Bu yaklaşımın gerekçesini burada epey ayrıntılı yazdım: https://github.com/colinhacks/zod/issues/4371
      npm’in Zod’un içinde bulunduğu durumu iyi yönetemediği doğru. Ancak Zod, neredeyse hiçbir kütüphaneyi kabul etmeme kısıtı altında. Onlarca-yüzlerce kütüphane "zod" üzerinden arayüzleri/sınıfları doğrudan içe aktarıp kendi public API’lerinde kullanıyor
      Bu tür kütüphanelerin, Zod her major sürüm artırdığında yeni major sürüm çıkarması gerekiyor ve Zod’da bu herkes için acı verici bir sürüm çığına yol açabilir. Açıkçası ekosistemin önemli bir kısmı sonsuza dek v3’e kilitlenecek gibi görünüyordu
      Bu yüzden Go’ya benzer şekilde, uyumluluğu bozan her sürüm için yeni paket sürümü çıkarmak yerine yeni bir alt yol eklemeyi seçtik. TypeScript ekosisteminde zod@^3.25.0 şeklinde tek bir peer dependency ile "zod/v3" ve "zod/v4" aynı anda desteklenebilir
    • “Peer dependency’ler bozulduğu için v4, v3’müş gibi davranıyor” sonucu doğru görünmüyor. Zod v4’ün v3’ün içine dahil edilmesinin, kullanıcıların kademeli olarak geçebilmesi için olduğunu düşünüyorum
      Yani kullanım yerlerini tek tek import ... from 'zod/v4' olarak refactor edip, bitince tamamen v4’e yükseltme akışı
    • Olumsuz bir şey söylenince her ne olursa olsun upvote alıyor gibi. Bu karar, npm’in kendisinin özsel bir sınırından ziyade, uyumluluğu bozan değişiklikleri fazla olan kütüphaneleri kademeli olarak değiştirmeyi sağlayan pratik bir yönteme daha yakın
    • Yıllardır yalnızca npm kullandığım için bakış açım daralmış olabilir, ama v3’ten v4’e tek seferde büyük bir geçiş yapmak yerine tekrarlı olarak migrate etmenin daha iyi yolu nedir merak ediyorum
    • Bu yalnızca npm’e özgü bir sorun değil. Bir bağımlılığın başka bir transitif bağımlılıkta eski bir sürüme dayanması sorunu aslında tüm ekosistemlerde ortaya çıkıyor
      Hatta npm, gerekirse birden çok sürümü aynı anda çalıştırabildiği veya transitif bağımlılık grafiğinin bir kısmını seçici olarak override edebildiği için daha fazla çıkış yolu sunuyor
      Hangi paket yönetim sistemi bu sorunu çözüyor? Maven gibi “stabil” platformlar bile Apache Commons’ın v2’den v3’e geçişinde olduğu gibi yeni namespace ile sürüm çıkararak bu tür sorunları ele alıyor

  • Uzun zamandır merak ettiğim bir soru var. Zod’un buna uyabileceğini duymuştum ama dokümanlara bakınca nasıl yapılacağını pek anlayamadım.
    Sunucu API’sinin ifade edebileceğinden daha incelikli bir tip döndürdüğünü varsayalım. Örneğin api/:postid/author bir User döndürüyor, ama bu normal bir User da olabilir anonim bir User da; bu yüzden username, location gibi alanlar null gelebilir. Bu durumda User nesnesini ayrıştırılmış union olarak ifade etmek isteyebilirsiniz.
    Başka endpoint’lerden gelen nesnelerde de tip dönüşümü gerekebilir. User bazen Post[] içerebilir; Post da moderatör gönderisiyse özel özelliklere sahip olabilir.
    Eskiden normalizeUser() ve normalizePost() gibi fonksiyonlar yazıyordum ama kısa sürede dağınıklaştı. Her endpoint User/Post modelinin farklı alt kümelerini döndürdüğü için yaklaşık 5 tane normalizePost yazmak zorunda kaldım; çok karmaşık oldu. Bu tür sorunlar genelde nasıl çözülüyor merak ediyorum.

    • Ayrıştırılmış union kullanmak uygun olabilir.
      status gibi bir ayrıştırıcı alanı temel alıp success ve failed nesnelerini ayırmak gibi. Moderatörlere özel çok sayıda özellik varsa ama hepsini tek tek listelemek ya da kontrol etmek istemiyorsanız passthrough davranışı tanımlayabilirsiniz.
      Birden fazla metodun farklı şemaları olsa bile ortak bir bölüm varsa paylaşılan bir nesne şeması oluşturup, bunun üstüne ek alanlar bindirilmiş nesneler oluşturabilirsiniz. Olasılık sayısı fazlaysa yine dağınık olacaktır; ama durum zaten dağınıksa, doğrulayıcı en azından bu dağınıklığı doğrulayabilir.
    • İdeal olarak User’ın hangi şekillerde olabileceğine dair tek bir doğruluk kaynağı olmalı. Bu, User ve AnonymousUser gibi bir ayrıştırılmış union olabilir.
      Full-stack TypeScript değilse, örneğin Python backend’de farklı User biçimlerini Pydantic modelleri ve union’lar olarak tanımlayıp, OpenAPI/GraphQL şeması üretimi ve kod üretimiyle TypeScript istemci tipleri oluşturabilirsiniz.
    • Kullanım senaryosunu daha iyi bilmeden çözmek zor, ama union içindeki tüm tiplere "user_type" gibi bir ayrıştırıcı özellik eklerseniz genel durumları ve özel durumları ele almak kolaylaşır.
      Örneğin user.user_type === 'authenticated' kontrolünü yaptığınızda tip sistemi, bunun ardından user.name kullanılabileceğini bilir.
    • Bu özel durumda doğrudan yardımcı olmayabilir ama GraphQL bu tür şeyler için oluşturuldu.
      GraphQL sorguları için TypeScript kütüphaneleri, seçilen alan biçiminden yanıt biçimini dinamik olarak çıkarabilir. { user { username posts { text } } } seçerseniz posts içeren bir yanıt tipi olur; yalnızca { user { username } } seçerseniz posts özelliği tamamen çıkar.
    • Sunucu tipleri dışa aktarmalı. İstemcide tipleri elle yazmak mantıklı değil.
      Sunucu gönderdiği veriyi bilir; bu yüzden bu bilgiyi metadata olarak istemciye sunmalı. Pratikte bu, Python backend’in Pydantic şemaları kullanması, bunlara dayanarak OpenAPI spesifikasyonunu otomatik üretmesi ve istemcinin tipleri üretmesi şeklinde olabilir.

  • Zod, gördüğüm alternatiflerden çok daha iyi; ama böyle açık doğrulama gereksiniminin kendisi bazen modern web geliştirmenin geldiği nokta açısından bir başarısızlık gibi hissettiriyor.
    Full-stack geliştirmede aynı şekli birden fazla biçimde tarif etmek zorunda kalmak çok can sıkıcı. JS girdi doğrulaması, API tanımı için Swagger, sunucu tarafı girdi doğrulaması, şema uygunluğu için ORM, ayrıca sunucu ve istemci için ayrı TypeScript tanımları gerekiyor; bunlar sıkıcı.

    • TypeScript’in statik kontrol/derleme zamanı odaklı bir sistem olmakta ısrar etmesi tüm ekosistem için üzücü bir yara. TypeScript’in bir runtime doğrulayıcı olmasını istemiyorum; ama sınıflar, fonksiyonlar ve nesneler için faydalı şekilde kullanılabilecek tip verilerini dışa aktarmasını isterdim.
      TypeScript elimizdeki en iyi tek doğruluk kaynağı gibi hissettiriyor; ama gerçekte reflection yapmaya çalışan araçların her biri kendi modelini ve builder’ını yeniden tanımlıyor. Reflection’ın merkezde olduğu 5 büyük alan var ve her birinin birden fazla implementasyonu bulunuyor.
      Eski bir TypeScript tip yayma aracı olan reflect-metadata, runtime tip bilgisinin bir kısmını sağlıyor; ancak çok eski decorator ve metadata spesifikasyonlarını hedefliyor: https://www.npmjs.com/package/reflect-metadata
      Belki de birleşmenin başlangıcına gelmiş olabiliriz. Standard Schema projesi, başlıca doğrulama kütüphanelerinin çoğundan destek alıyor gibi görünüyor. Ancak bunu API tanımı veya ORM araçlarına kadar genişletmek hâlâ çok erken aşamada.
      https://github.com/standard-schema/standard-schema?tab=readm...
    • Aslında bu, böyle araçların temel noktası. Bir kez tanımlarsınız ve altındaki her şeyi dinamik olarak üretirsiniz.
      Zod şemasında bir kez değişiklik yaptığınızda, tip kontrolüyle birlikte tüm uygulamaya yayılır. Zod şeması tek doğruluk kaynağı hâline gelir.
    • Genelde veriyi orada burada yeniden tanımlamanıza gerek yok. Zod’a dönüştüren veya Zod’dan dönüştüren çok fazla araç var.
      Elinizde zaten JSON Schema/Swagger şeması varsa buradan Zod üretebilirsiniz. TypeScript ORM kullanıyorsanız neredeyse kesinlikle bir Zod generator’ı vardır.
      Açıkçası Zod o kadar yaygın kullanılıyor ki benim için stack’teki diğer şeylerin dayanabileceği birleşik şema tanımı hâline geldi. Tipleri doğrudan tanımladığı için geliştiriciler gerçekten güncel tutuyor. Şirketin Swagger dokümanları değişikliklerin hep gerisinde kalıyor.
    • Tüm API’ler deneysel ve sürekli değişip evrilen durumda; web de öyle.
      Mevcut düzenin kabul edilebilir olduğu tek durum, sadece sonucu isteyen ve nasıl yapıldığıyla ilgilenmeyen müşteriler ve işverenlerle çalıştığınız zamandır. Böyle bir bağlamda bu talihsiz karmaşıklık katmanları en azından faturalandırılabilir saatleri artırır.
    • Modern web geliştirmenin karmaşık olduğundan şikâyet eden birçok kişi, tüm bunları sadece TypeScript ve Zod ile değiştirme önerisinden de muhtemelen hoşlanmayacaktır.
      Elbette Zod’un, kişinin seçtiği TypeScript şema tanımı ve doğrulama kütüphanesi olduğu varsayımıyla.

  • Zod 4 iyi görünüyor, ancak en son iyileştirmeler dahil edilse bile ArkType hâlâ tek haneli katlar düzeyinde daha hızlı
    Geriye dönük uyumluluk ve söz dizimi uyumluluğu için, tamamen sıfırdan başlamış bir kütüphane kadar hızlı yapmak bazen çok daha zor olabiliyor. Yakın tarihli bir projede bu araçların hepsini analiz ettik ve kısmen bu nedenle ArkType’ı seçtik. TypeScript kullanım deneyimi de daha iyi hissettirdi

    • Hız metriklerine baktım; bu hızın nerede fark yarattığını açıklayabilir misin diye merak ediyorum
      Biz Zod’u yalnızca form doğrulaması için kullanıyoruz, bu yüzden “bu neden önemli?” diye düşünüyorum. İnsanların yüksek iş hacimli API giriş mesajları gibi şeyleri doğruladığı ve performansın daha önemli hâle geldiği durumlar mı var acaba
    • ArkType’ı TypeBox yerine neden seçtiğini merak ediyorum
    • İlginçtir, araştırırken o aracı hiç görmemiştim. Ben de özellikle TypeScript kullanım deneyimine bakıyordum
      Yine de Zod’dan geçeceğimi sanmıyorum
    • ArkType yazması kâbus gibi, Zod ise yazması rahat

  • Zod ekibini yeni sürüm için tebrik ederim. Fazla olumsuz duyulma riskini göze alarak söyleyeyim: migrasyon rehberinde listelenen uyumluluğu bozan değişikliklerin sayısını düşününce ürperiyorum
    Zod’a ciddi ölçüde bağımlı bir proje için bunun geliştirici odağı ve zamanı gerektiren göz korkutucu bir iş olacağını düşünüyorum. İş yerinde 4–5 yıllık birkaç frontend projesinin bakımını yaptığım için özellikle empati kuruyorum
    Büyük React projeleri genelde çok sayıda kütüphaneye dayanıyor; her kütüphane büyük değişiklikler yayımladığında, hele dokümantasyon da yetersizse, bir anda bunaltıcı hâle geliyor. JavaScript ile çalışırken en sevmediğim şeylerden biri bu; her şeyi hizalı tutup sorunsuz çalışmaya devam ettirmek bitmeyen bir yokuş gibi hissettiriyor

    • Tamamen katılıyorum. Birkaç büyük Next.js uygulaması işletiyoruz; geçen yıl Next.js 14 → 15’teki büyük cache değişiklikleri, Next.js pages → app router, React 18 → 19, Eslint 8 → 9, Tailwind 3 → 4 ile uğraşmak zorunda kaldık
      Açıkçası kâbustu; keşke Django ile yapmış olsaydık diye düşündüm. Beklediğimin aksine Tailwind 3 → 4 migrasyonu en acı verici olanlar arasındaydı
    • Bu yüzden ayrı bir mini edisyonuyla birlikte çift sunum yaklaşımını seçtiler. Paket yöneticisine dokunmadan kademeli migrasyon yapmak daha kolay
      mini edisyonuyla ilgilenmeyen kullanıcıların bu kısmı önemsemesine gerek yok. Ancak mini edisyonunun tree-shaking avantajı o kadar büyüktü ki alternatif geliştirmeyi teşvik ediyordu; Zod’un bunu benimsemesi ya da gerilemesi gerekiyordu
    • Sadece LLM kullanın yeter

  • Prodüksiyonda binlerce kullanıcısı olan bir SaaS’ı bizzat işleten bir full-stack geliştirici olarak, SPA yapmamaya ve JS frontend framework’ü kullanmamaya karar verdiğim için hiç bilmediğim ne kadar çok problem olduğunu bazen memnuniyetle fark ediyorum
    Zod/ArkType gibi bir şeye ihtiyaç duyabileceğimi hiç düşünmedim bile; ilk kez duyuyorum ve kullanacağım bir durum da yok
    SPA yapmanın gerektirdiği emek, karmaşıklık ve araç miktarı beni şaşırtıyor. SPA yapmamaya karar verdiğinizde belirli bir problem kümesi tamamen ortadan kalkıyor. Bunun yerine tarayıcıyı tasarlandığı şekilde, tam sayfa yenilemeleri ve backend geliştirme odağıyla kullanıyor; ara sıra reaktivite eklemek için Laravel Livewire gibi yalnızca backend taraflı framework’lerden yararlanıyoruz
    Erişim kontrolünden doğrulamaya ve durum yönetimine kadar her şey basit. Uygulama hızlı, responsive, modern, SEO dostu ve prodüksiyonda binlerce kişiye hizmet veriyor

    • 5’ten fazla ekibin birlikte çalıştığı iki büyük projede Zod ve Protobuf kullanarak şema evriminin iyi işlemesini sağladık. Hafif bir frontend olsa bile backend’de şemayı doğrulayan bir şey kullanmak anlamlı
      Sonuçta bir yerlerde bir şema var. Veritabanı sisteminde tanımlanmış olabilir ya da ORM modelinde tanımlanmış olabilir. Ancak büyük projelerde şemayı veritabanı sistemine veya ORM’ye koymak çok zor sorunlar doğurabildiği için biz Zod ve Protobuf kullanıyoruz. Protobuf’un da Zod ya da benzeri bir şeyle tamamen değiştirilebileceğini düşünüyorum
      Birleşik Krallık Post Office skandalında Horizon adlı bir IT sistemi vardı: https://en.wikipedia.org/wiki/British_Post_Office_scandal
      Ayrıntıları okuyunca, Zod gibi şema doğrulaması olsaydı bu skandalı önlemeye katkı sağlayabilirmiş gibi geldi. Toplu dava mahkeme belgelerinin teknik ekinde de şema kullanımının yokluğundan bahsediliyor: https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office...
    • Zod’un SPA ile ilgisi yok ve yalnızca frontend aracı da değil. Kodda giriş doğrulaması yapmıyor musunuz?
    • Gözlerini kapatınca bazen bütün bir problem kümesi yok oluverir
    • Sunucu tarafı doğrulamayı nasıl yaptığınızı merak ediyorum
      Şu an kulağa savunmacı şekilde bir sürü if yazıyormuşsunuz gibi geliyor. Daha kötüsü, yalnızca HTML’in istemci taraflı form doğrulamasına güveniyor da olabilirsiniz
    • Bizde veri pipeline’ının bir parçası olarak kullanılan, sadece backend taraflı çok sayıda Zod şeması var. Bu yüzden yalnızca SPA problemlerini çözmek için var olan bir araç gibi görünmüyor

  • Uzman olmadığım için temkinliyim ama JSON Schema şema tabanlı olduğundan TypeScript dışındaki dillerde de doğrulayıcılar uygulanabildiği için iyi bir seçenek olabileceğini düşünmüştüm
    https://ajv.js.org bu tür JSON Schema kütüphanelerinden biri. Zod ile kıyaslandığında nasıl olduğunu merak ediyorum

    • Zod yalnızca JSON doğrulamak için bir araç değil. Dönüştürme olmadan JSON ile ifade edilemeyen nesneleri, örneğin tarihleri veya sınıf örneklerini de doğrulayabiliyor
      İsterseniz JSON dönüştürücü olarak da kullanabilirsiniz. Örneğin bir string alıp ISO tarih string'i olup olmadığını doğrulayan ve Date nesnesi çıktısı veren bir şema yazabilirsiniz
    • Zod 4, Zod şemalarını JSON Schema'ya dönüştürmeyi yerel olarak destekliyor. Eskiden bu üçüncü taraf kütüphanelerle de mümkündü
      Önemli fark ön işleme ve refine. Zod'da doğrulama öncesinde callback sağlayabilirsiniz; bu çok kullanışlıdır ama JSON ile ifade edilemez. Örneğin tarih doğrulamasından önce MM/DD/YYYY'yi DD/MM/YYYY'ye çevirmek sanıldığından daha sık işe yarar
    • Böyle durumlarda JSON Schema iyi bir seçenek ve TypeBox bunu üretmenin makul bir yolu
      Doğrulama için AJV'yi ya da TypeBox'ın kendi şema doğrulama sistemini kullanabilirsiniz. İkincisi çok daha hızlıdır ama yalnızca senkron çalışır; AJV ise veritabanı kontrolü gibi asenkron doğrulama seçeneklerine sahiptir
    • Diller arası doğrulama için JSON Schema doğru tercih. Bunu OpenAPI ile sarmalarsanız iyi API dokümantasyonunu da bedavaya elde edersiniz

  • Bu konu etrafındaki olumsuz tepki şaşırtıcı
    Zod v4'ün erken bir sürümünü test ettim ve yeni API hoşuma gitti, ancak geçiş yolunun nasıl olacağı konusunda çok endişeliydim. Hatta tamamen yeni bir paket adıyla yayımlanmasını önermeyi bile düşünmüştüm
    Ama yazarın yaklaşımı akıllıca. Tüm bağımlılıkların güncellenmesini beklemeden benim gibi kişilerin v4'ü hemen benimsemesine olanak tanıyor

    • İyi bir yol. Doğrulama gibi bir konuda ya hep ya hiç tarzı bir geçişi kaldırmanın bir yolu yok

  • Yeni bir projede Zod'u daha yeni kullanmaya başlamıştım; bundan daha iyi bir zaman olamazdı
    Şu an görünenlere göre v4'e geçmek için gerçekten çok şey değiştirmem gerekecekmiş gibi görünüyor