podexit: CocoaPods trunk salt okunur olunca hangi pod'lar güncelleme almayacak

İçindekiler

• Problem
• Tasarım kararları ve alternatifler
• Bir hata ve öğrettikleri
• Kullanım
• Sınırlar

Problem

CocoaPods trunk, 1–7 Kasım'daki deneme haftasının ardından 2 Aralık 2026'da salt okunur oluyor.

Bu konuda söylenenlerin çoğu, değişikliğin kendisinden daha gürültülü. Build'ler çalışmaya devam

ediyor: Specs reposu ve CDN açık kalıyor, pod install daha önce yayınlanmış her sürümü çözmeye

devam ediyor. Duran şey daha dar ve gözden kaçması daha kolay: trunk'ta yayınlanan bir pod, bakımcısı

onu başka bir yoldan (çoğunlukla Swift package olarak) yayınlamadıkça, güvenlik düzeltmeleri dahil

bir daha yeni sürüm alamayacak.

Firebase'te tarih daha erken. Geçiş sayfasına göre CocoaPods'taki son ana sürüm 12; Firebase Ekim

2026'da oraya yayın yapmayı bırakıyor ve bu karar listelenen pod'ları "ve onların alt bağımlılıklarını"

kapsıyor.

Yani Podfile.lock'u olan bir ekibin her bağımlılık için iki sorusu var: Bu pod güncelleme almayı

bırakıyor mu, ne zaman? Geçebileceğim bir Swift package zaten var mı? Cevaplar native iOS uygulaması,

Flutter uygulaması ya da plugin'i ve React Native ya da Expo uygulaması için farklı, çünkü son

ikisinde pod'ların çoğu yerel yollardan (.symlinks/plugins, node_modules) geliyor ve trunk

üzerinden değil pub ya da npm üzerinden güncelleniyor.

podexit bu iki soruyu projede zaten bulunan lockfile'dan cevaplıyor. Projeye hiçbir şey kurmuyor,

hiçbir dosyayı değiştirmiyor; yalnızca kendi cache'ini ve istenen raporu yazıyor.

Tasarım kararları ve alternatifler

Podfile değil Podfile.lock. Podfile ne istendiğini söyler; lockfile ise CocoaPods'un neyi

çözdüğünü: tam sürümler, subspec'ler, bağımlılık grafı ve her pod'un nereden geldiği. Cevabı bu son

bilgi belirliyor. Yerel yoldan ya da git kaynağından gelen bir pod, trunk'ın salt okunur olmasından

etkilenmez; trunk'tan gelen etkilenir. parseLockfile, Firebase/Analytics gibi subspec'leri kök

pod'a katlıyor ve her birinin kaynağını saklıyor.

CocoaPods plugin'i yerine Node.js ve TypeScript. Ruby ile yazılmış bir plugin projeye eklenmek

zorunda kalır ve pod install içinde çalışırdı. Bu cevaba ihtiyaç duyanlar arasında Flutter ve React

Native geliştiricileri de var; onlarda Node.js zaten kurulu ve npx, projeye bir şey eklemeden aracı

çalıştırıyor. Bedeli şu: yalnızca native iOS geliştiren birinde Node.js olmayabilir. Bu durum için

muhittincamdali/tap içindeki Homebrew formülü release tarball'unu kuruyor.

Pod başına iki ayrı cevap. Güncelleme durumu frozen-on-trunk, capped, not-affected ya da

unknown olabiliyor. Swift package durumu ise spm-available, no-spm, unknown ya da

not-checked. İkisini tek bir puana karıştırmak en işe yarar durumu gizlerdi: donmuş ama bugün

taşınabilecek bir pod.

Yayıncı sınırları kod değil, kaynaklı veri. Firebase sınırı data/publisher-policy.json

dosyasında duruyor: 20 listelenmiş pod, son ana sürüm 12, yayının durduğu ay 2026-10 ve bir

includesSubdependencies bayrağı. Her kayıt kaynağını gösteriyor, dosyayı bir zod şeması doğruluyor

ve haftalık bir workflow (data.yml) gösterilen kaynakların hâlâ cevap verdiğini kontrol ediyor.

Verinin kendi dataVersion değeri var; bu değer Markdown ve JSON raporlarında görünüyor.

Package.swift kontrolü raw.githubusercontent.com üzerinden. Upstream kontrolü, Package.swift

için bir HEAD isteği: önce varsayılan dalda, podspec bir tag veriyorsa ardından kilitli tag'de.

Raw host üzerinden gitmek, kimlik doğrulamasız isteklerdeki REST API kotasının dışında kalmayı

sağlıyor; HEAD isteği de gövde indirmiyor. GITHUB_TOKEN ya da GH_TOKEN yalnızca GitHub

host'larına, özel upstream repolar için gönderiliyor. Kilitli tag'e bakmak önemli: package yalnızca

daha yeni sürümlerde varsa rapor bunu açıkça söylüyor; geçişin bedava olduğunu ima eden düz bir

"yes" yazmıyor (analyze.test.ts: "flags a package that exists only after the locked version").

Tek fetcher, üç kullanım. Ağdan gelen her şey bir Fetcher üzerinden geçiyor. CachedFetcher

her cevabı, method ve URL'nin hash'iyle adlandırılan bir JSON dosyasına yazıyor; 404'leri saklıyor

(eksik bir Package.swift gerçek bir cevaptır), 5xx ve 429'u saklamıyor. Önce geçici dosyaya yazıp

sonra yeniden adlandırdığı için iki çalıştırma hiçbir zaman yarım dosya okumuyor. Arkasına bir

OfflineFetcher konduğunda aynı dosyalar --offline modunu, testleri ve terminal demolarını

besliyor. Beş fixture; native, Flutter uygulaması, Flutter plugin'i, Expo ve React Native ile

oluşturulup CocoaPods 1.16.2 ile çözülmüş gerçek projeler. Trunk ve GitHub cevapları 14 Ekim 2026'da

kaydedildi.

src/core/ saf kod (ayrıştırma, sürüm karşılaştırma, sınıflandırma; I/O yok) ve eksik bir cevap

hata olarak değil, gerekçesiyle birlikte unknown olarak raporlanıyor.

Bir hata ve öğrettikleri

0.1.0 çıkmadan önceki ilk uygulama yalnızca Firebase'in listelediği 20 pod'u sınırlıyordu. Native fixture'da bu yüzden

FirebaseCoreInternal, FirebaseSessions, GoogleUtilities ve nanopb, Firebase onları Ekim'de

bırakmasına rağmen "frozen after Dec 2" görünüyordu. bf0e1ba commit'i (PR #7) bunu düzeltti:

classifyLockfile artık önce her pod'u tek başına sınıflıyor, sonra listelenen her sınırlı pod'dan

başlayarak bağımlılık grafında genişlik öncelikli (breadth-first) yürüyor ve ulaştığı trunk pod'larını

da sınırlıyor. Genişlik öncelikli olması bilinçli: via alanı en yakın listelenmiş pod'u gösteriyor.

Yerel yol, git ya da özel spec'ten gelen pod'lara dokunulmuyor. Sınırlanan bir alt bağımlılık

"capped at 12.x" değil "capped with Firebase" etiketi alıyor, çünkü GoogleUtilities'in kendi sürüm

çizgisi var. Native fixture'daki sonuç 28 pod: 15 capped, 11 frozen, 2 not affected.

Daha öğretici ders, 0.1.0 sürümünün ardından geldi. Girdi güvenilir değil: bir Podfile.lock

pull request ile gelebilir ve YAML'ın çift tırnaklı kaçış dizileri kontrol karakteri taşımasına izin

veriyor. Terminal raporu pod adlarını, sürümleri ve yolları geldiği gibi yazdırıyordu; bu yüzden

"Evil\e[31mPod (1.0.0)" gibi bir giriş terminale ham bir escape dizisi gönderiyordu. Düzeltme dört

adımda geldi ve her adımın kendi testi var:

• e5a86c3 (PR #19): Terminal ve Markdown raporları C0, DEL ve C1 kontrol karakterlerini U+FFFD ile

değiştiriyor; böylece müdahale ekranda etki etmek yerine görünür kalıyor.

• c2db6a9 (PR #22): JSON raporu da. İlk düzeltme, JSON.stringify'ın kontrol karakterlerini zaten

kaçışladığı varsayımıyla JSON'u atlamıştı; oysa yalnızca U+0000–U+001F aralığını kaçışlıyor. DEL ile

U+009B (8 bitlik CSI) gibi C1 kontrol karakterleri olduğu gibi geçiyordu.

• 316e164 (PR #22): stderr'e yazılan mesajlar. "Unexpected PODS entry" içinde alıntılanan bir lockfile

girdisi OSC 52 ile panoya yazma ya da ekran temizleme taşıyabiliyordu; "Checking" satırındaki bir

klasör adı da öyle.

• b06bb49 (PR #22): Pull request yorumları için hazırlanan Markdown raporu yalnızca | karakterini

kaçışlıyordu. Pod adındaki bir backtick kod alanını kapatıp görsel, bağlantı ya da @mention

ekleyebiliyordu. Değerler artık içlerindeki en uzun backtick dizisinden daha uzun çitle açılan kod

alanlarına yazılıyor, repo URL'leri de percent-encode ediliyor.

İlk düzeltme v0.1.0 tag'inden sonra geldiği için 0.1.0 tarball'unda yok; dördü de 0.1.1'de var.

Çıkan ders varsayımlarla ilgili: "serializer bunu zaten kaçışlıyor" cümlesi bir aralık için doğru,

diğeri için yanlıştı ve bunu ancak C1 karakteri içeren bir test gösterdi.

0.1.2 sürümü davranışı değiştirmedi; yalnızca yardım metnindeki ve user agent'taki paket adı güncellendi. npm, kapsamsız adı mevcut bir paketle fazla benzer bulup reddetti;

bu yüzden paket @mcamdali/podexit adıyla yayında, komut ise hâlâ podexit (24d4f1b).

Kullanım

Proje klasöründe:

1npx @mcamdali/podexit

Yol verilmezse podexit Podfile.lock, ios/Podfile.lock, macos/Podfile.lock,

example/ios/Podfile.lock ve example/macos/Podfile.lock konumlarında bulduğu her lockfile'ı

okuyor. --format markdown pull request için bir rapor üretiyor; --format json ise script'lere her

pod'un updates.status, swiftPackage.status değerlerini, trunk'taki son sürümü ve her cevabı

açıklayan bir cümleyi veriyor. 0 çıkış kodu raporun yazıldığı anlamına geliyor; podexit rapor

veriyor, bulduğu şey yüzünden build'i başarısız saymıyor.

CLI, programatik bir API'nin üzerindeki ince bir katman. README'deki örnek şöyle:

<!-- prettier-ignore -->

1import {
2  analyzeLockfile,
3  buildReport,
4  CachedFetcher,
5  HttpFetcher,
6  loadPublisherPolicy,
7  render,
8} from '@mcamdali/podexit';
9 
10const policy = loadPublisherPolicy();
11const fetcher = new CachedFetcher(new HttpFetcher({ userAgent: 'my-tool' }), {
12  directory: '.cache',
13});
14const lockfile = await analyzeLockfile(text, 'ios/Podfile.lock', { fetcher, policy });
15console.log(render(buildReport([lockfile], { policy, offline: false }), 'markdown'));

Çalıştırılabilir sürümü examples/api/summary.mjs: beş fixture'ı çevrimdışı okuyor ve test

süitinde çalıştırılıyor. examples/github-actions/podexit.yml ise Podfile.lock değiştiren her pull

request'in job özetine raporu ekliyor.

Sınırlar

• JSON yapısı schemaVersion 0; 1.0'dan önce değişebilir.
• podexit bir pod'u hangi npm ya da pub.dev paketinin getirdiğini söylemiyor (0.3'te planlı); pod'ları

Swift package ürün adlarına ve sürümlerine eşlemiyor (0.5'te planlı). Bir repoda Package.swift

bulunması, ihtiyaç duyulan ürünü sunduğunu kanıtlamaz.

• Podspec'i GitHub dışında bir host'u (örneğin bir binary indirmesini) gösteren pod unknown kalıyor.
• Yayıncı politikası elle güncelleniyor. Haftalık kontrol ölü kaynakları yakalıyor, bir yayıncının

eklediği yeni pod'ları değil.

• Rapor veriyor, geçişi yapmıyor. Henüz --fail-on, SARIF çıktısı ya da GitHub Action yok.
• Testler tek günde kaydedilmiş beş fixture kullanıyor. CI Linux'ta (Node.js 22 ve 24) çalışıyor;

Windows'ta test edilmedi.

Repo 14 Ekim 2026'da açıldı; 0.1.0 aynı gün çıktı, 0.1.1 ve 0.1.2 15 Ekim'de geldi.

Kaynak kod: github.com/muhittincamdali/podexit