Dependency Güncellemelerinde Doğru Strateji Nedir? Güvenlik Yaması, Minor ve Major Sürümleri Ayırmak

Kısa özet Bütün dependency güncellemeleri aynı risk seviyesinde değerlendirilmemelidir. Security update, patch, minor, major ve prerelease güncellemelerinin önceliği ve test derinliği farklı olmalıdır. Semantic Versioning 2.0.0’a göre MAJOR.MINOR.PATCH yapısında patch sürümü backward-compatible bug fix, minor sürümü backward-compatible yeni özellik, major sürümü ise backward-incompatible API değişikliği anlamına gelir. Ancak SemVer bir sözleşmedir, güvenlik garantisi değildir; paket sahibi SemVer’i hatalı uygulayabilir ve özellikle 0.x sürümlerinde public API’nin stabil kabul edilmemesi gerektiği standardın kendisinde belirtilir. (Semantic Versioning) Bu nedenle iyi dependency stratejisi: Patch’i otomatik merge etmek, major’ı sonsuza kadar bekletmek veya bütün güncellemeleri tek PR’da toplamak değildir. Daha sağlıklı model: Security → önceliklendirilmiş güvenlik akışı Patch → hızlı doğrulama Minor → standart regression testi Major → kontrollü migration Prerelease → yalnızca bilinçli kullanım şeklindedir.

Kısa doğrudan cevap

Bir dependency güncellemesinde önce şu soruyu sorun:

• Neden güncelliyoruz?

Ardından sürüm tipini değerlendirin. Güncelleme Varsayılan yaklaşım Test derinliği Kritik güvenlik yaması Hızlı önceliklendir Hedefli + regression Patch Fast lane CI + smoke Minor Standart lane CI + integration Major Migration lane Changelog + migration + geniş regression Prerelease Kontrollü/opt-in Ayrı değerlendirme Ancak güvenlik güncellemesi gerekirse major sürüme geçiş de gerektirebilir. Bu durumda: Security patch ≠ Her zaman patch version ayrımını yapmak gerekir.

SemVer bize gerçekte ne söylüyor?

Semantic Versioning 2.0.0 standardına göre:

1.4.2 │ │ │ ``` │ │ └─ PATCH │ └─── MINOR └───── MAJOR ``` anlamı şöyledir: Patch 1.4.2 → 1.4.3 Backward-compatible bug fix. Minor 1.4.2 → 1.5.0 Backward-compatible yeni functionality. Major 1.4.2 → 2.0.0 Backward-incompatible public API değişikliği. (Semantic Versioning) Bu ayrım dependency update otomasyonunun temelidir.

GitHub Dependabot da sürüm güncellemelerini SemVer seviyesinde patch, minor ve major olarak ayırabiliyor. (GitHub Docs)

Ama “patch = risksiz” demek neden yanlış?

SemVer size publisher’ın niyetini anlatır. Şunu garanti etmez: Patch sürümünde hiçbir regression yoktur. Örneğin bir patch:

• runtime davranışını değiştirebilir,
• TypeScript type’larını sıkılaştırabilir,
• performans regression’ı oluşturabilir,

yanlışlıkla breaking change içerebilir. Dolayısıyla: SemVer risk sınıflandırmasıdır; testin yerine geçmez. Patch güncellemenin avantajı daha dar değişiklik kapsamı beklememizdir. Ama yine de CI’dan geçmelidir. 0.x paketlerde özellikle dikkat Semantic Versioning standardı: 0.y.z sürümlerini initial development olarak tanımlar ve bu aşamada herhangi bir şeyin değişebileceğini, public API’nin stabil kabul edilmemesi gerektiğini söyler. (Semantic Versioning) Bu nedenle: 0.4.1 → 0.5.0 değişikliği pratikte büyük breaking change taşıyabilir. npm’in kullandığı node-semver caret davranışı da bunu hesaba katar. Örneğin: ^1.2.3 şunu kabul eder: >=1.2.3 <2.0.0 ama: ^0.2.3 şunu kabul eder: >=0.2.3 <0.3.0

çünkü caret, soldan ilk sıfır olmayan bölümü korur. (GitHub)

^ ve ~ ne anlama geliyor?

npm dependency tanımlarında sık görülen iki range:

{

"dependencies": {

• "foo": "^1.4.2",

"bar": "~2.3.1"

} } Caret ^ ^1.4.2 genel olarak: >=1.4.2 <2.0.0 aralığını kabul eder. Yani: patch ✅ minor ✅ major ❌ Tilde ~ ~2.3.1: >=2.3.1 <2.4.0 aralığıdır. Yani esas olarak patch seviyesinde hareket eder. npm hem caret hem tilde dahil çeşitli version range biçimlerini destekliyor. (npm Belgeleri) package.json ile gerçekten kurulan sürüm aynı şey değil Örneğin: {

"reactive-lib": "^3.2.0"

} yalnızca kabul edilen range’i belirtir. Gerçekte kullanılan dependency ağacı lockfile’da sabitlenebilir. npm’in package-lock.json dosyası dependency tree’nin tam bir temsilini saklar ve ekip arkadaşları, CI ve deployment ortamlarının aynı dependency tree’yi yeniden oluşturabilmesi için repository’ye commit edilmek üzere tasarlanmıştır. (npm Belgeleri) Bu nedenle: Dependency PR’ında yalnızca package.json değil, lockfile da review edilmelidir.

Lockfile neden kritik?

Bir direct dependency:

Package A değişirken onun altında: B C D E transitive dependency’leri de değişebilir. Dolayısıyla PR: A 2.1 → 2.2 gibi görünürken gerçek dependency graph’ında çok daha büyük değişiklik olabilir. GitHub Dependency Review, PR’da:

• eklenen,
• kaldırılan,
• güncellenen,

dolaylı olarak değişen

dependency’leri ve bilinen vulnerability bilgilerini gösterebiliyor. (GitHub Docs)

CI'da npm install yerine neden npm ci değerlendirilmeli?

npm’in güncel dokümantasyonunda npm ci, özellikle:

• CI,
• test platformları,

deployment gibi otomatik ortamlar için tasarlanmış clean-install komutu olarak tanımlanıyor.

npm ci:

• mevcut package-lock.json gerektirir,
• package.json ile lockfile uyuşmuyorsa hata verir,
• lockfile’ı değiştirmez,

dependency install’ını frozen hale getirir. (npm Belgeleri) Bu davranış dependency update pipeline’ında önemlidir. Çünkü CI’ın sessizce başka dependency tree oluşturmasını istemezsiniz. Dependency güncellemelerini beş lane'e ayırın Lane 1 — Security Update En yüksek öncelik. Lane 2 — Patch Hızlı bakım. Lane 3 — Minor Normal bakım. Lane 4 — Major Planlı migration. Lane 5 — Preview / Beta / RC Bilinçli deneysel kullanım. Bu model InoviqLab teknik önerisidir.

1. Security update nasıl ele alınmalı?

Önce şu sorular:

• Hangi vulnerability?

CVE/GHSA nedir?

Severity ne?

Bizim kullandığımız sürüm etkileniyor mu?

Vulnerable code path gerçekten reachable mı?

Fixed version hangisi?

Exploit public mi?

Internet-facing sistem etkileniyor mu?

olmalıdır. GitHub Dependency Review, dependency değişikliklerinde bilinen vulnerability’leri, severity’yi ve varsa fixed version’ı PR üzerinden gösterebiliyor. (GitHub Docs) Security update SemVer sırasını bozabilir Örneğin uygulama: foo 2.x kullanıyor. Vulnerability yalnızca: foo 3.1.4 ile düzeltilmiş olabilir. Bu durumda güvenlik remediation’ı: major migration haline gelir. GitHub’ın Dependabot davranışında da önemli bir ayrım var:

update-types ile patch/minor/major sınırlaması version updates için uygulanır; security updates bu allow kısıtından etkilenmez. (GitHub Docs)

Yani: Güvenlik akışı normal version-maintenance politikasından ayrı düşünülmelidir.

Security PR otomatik merge edilmeli mi?

Her durumda değil. Örneğin: lodash patch ile: authentication framework major update aynı riskte değildir. Daha doğru karar: Vulnerability severity + Exploitability + Dependency criticality +

Update scope

+ Test confidence üzerinden verilmelidir. Kritik security fix için önerilen pipeline Security alert ↓ Affected-version doğrulaması ↓ Fixed version tespiti ↓

Update branch

↓ Lockfile review ↓ Type-check ↓ Tests ↓ Security / dependency review ↓ Staging / smoke ↓ Production ↓ Monitoring Severe/actively exploited durumlarda normal release takviminden daha hızlı ilerlemek gerekebilir.

2. Patch update nasıl yönetilmeli?

Örneğin: 4.8.1 → 4.8.2 SemVer sözleşmesine göre backward-compatible bug fix’tir. (Semantic Versioning) Bu nedenle güçlü test suite’i bulunan projelerde patch güncellemeleri için fast lane oluşturulabilir. Örneğin: Patch PR ↓

npm ci

↓ Type-check ↓ Lint ↓ Unit tests ↓ Build ↓ Dependency review ↓

Merge

Patch otomatik merge edilebilir mi?

Bazı dependency’lerde evet. Örneğin:

• test utility,
• lint rule,

non-critical dev tooling için güçlü CI sonrası otomatik merge mantıklı olabilir. Ancak:

• database driver,
• authentication,
• payment SDK,
• framework runtime,

ORM patch dahi olsa daha dikkatli değerlendirilebilir. Bu yüzden:

Update type + dependency criticality

birlikte kullanılmalıdır.

3. Minor update nasıl yönetilmeli?

Örneğin: 3.4.8 → 3.5.0 SemVer’e göre backward-compatible yeni functionality içerebilir. (Semantic Versioning) Bu tip update:

• yeni API,
• deprecated API,
• internal refactor,

yeni default davranış getirebilir. Dolayısıyla patch’ten biraz daha geniş test mantıklıdır. Minor update kontrolü Önerilen: release notes/changelog peer dependency değişiklikleri runtime requirement TypeScript requirement deprecation test build integration test kontrolü. Özellikle framework/plugin ekosistemlerinde minor release’in diğer paketlerle compatibility etkisi olabilir.

4. Major update neden ayrı PR olmalı?

Major:

4.x → 5.x backward-incompatible public API değişikliği olabileceği anlamına gelir. (Semantic Versioning) Bu nedenle major güncellemeleri: minor + patch toplu PR içine gömmek review’u zorlaştırır. GitHub da Dependabot dokümantasyonunda minor/patch güncellemelerinin gruplanıp major güncellemelerin ayrı PR olarak bırakılabildiği modeli doğrudan örnekliyor. (GitHub Docs) Major update aslında mini migration projesidir Kontrol edilmesi gerekenler: Migration guide Breaking changes Removed API Deprecated API Runtime requirements Peer dependencies Config değişiklikleri Database/schema etkisi Build pipeline

Deployment/rollback

Major update'i aylarca bekletmek doğru mu?

Her zaman değil. Şu davranış: Major geldi ↓ Ignore ↓ 2 yıl geçti ↓ 3 major geride daha büyük migration borcu yaratabilir. Örneğin: v4 → v5 migration’ı yönetilebilirken: v4 → v8 aynı anda:

• dört migration guide,
• eski deprecated API’ler,
• runtime değişimi,

config değişimi gerektirebilir. Bu nedenle major update: hemen merge edilmemeli ama süresiz ertelenmemelidir.

Büyük framework major'larında ayrı branch daha mı iyi?

Bazen. Örneğin: Next.js React Angular ORM Node major upgrade’i çok sayıda dosyayı etkiliyorsa: dependency update PR olmaktan çıkıp: migration project haline gelebilir. Bu durumda ayrı:

• branch,
• test planı,
• staging,

rollout kullanılabilir.

5. Prerelease güncellemeleri farklı sınıftır

Örneğin: 5.0.0-beta.1 5.0.0-rc.2 SemVer specification prerelease sürümlerinin stabil kabul edilmemesi ve ilgili normal sürümün hedeflenen compatibility beklentilerini karşılamayabileceğini açıkça belirtiyor. (Semantic Versioning) Dolayısıyla: beta preview alpha rc versiyonlar production’da otomatik update lane’e konulmamalıdır.

Dependabot nasıl yapılandırılabilir?

Örneğin npm projesinde minor ve patch güncellemelerini aynı PR’da gruplayıp major’ları ayrı bırakabilirsiniz:

version: 2 updates:

• package-ecosystem: "npm"

directory: "/" schedule: interval: "weekly" groups: minor-and-patch: applies-to: version-updates patterns:

• "*"

update-types:

• "minor"
• "patch"

Bu yapı ile eşleşen minor/patch version update’leri gruplanır; major güncellemeler individual PR olarak kalır. GitHub bu stratejiyi Dependabot dokümantasyonunda örnekliyor. (GitHub Docs)

Ama bütün minor/patch dependency'leri tek PR'a koymak her zaman iyi mi?

Hayır. Örneğin: 27 dependency

tek PR’da değişirse CI başarısız olduğunda:

• Hangi paket bozdu?

sorusunun cevabı zorlaşabilir. Bu yüzden grouping şu alanlara göre yapılabilir: frontend tooling testing eslint types AWS SDK Angular packages GitHub Dependabot group’ları dependency name, dependency type ve SemVer level gibi kriterlere göre oluşturabiliyor. (GitHub Docs) Production ve dev dependency aynı riskte değil Örneğin: {

"dependencies": {
"payment-sdk": "..."

• },

"devDependencies": {
"eslint-plugin-x": "..."

} } ikisi farklı production riskine sahiptir. Dependabot desteklenen package manager’larda update policy’yi production ve development dependency tipine göre ayırabiliyor. (GitHub Docs) Bu iyi bir otomasyon fırsatıdır. Örnek risk politikası Dev dependency patch/minor CI ↓ Auto-merge olabilir Production dependency patch CI + Smoke ↓ Merge Production minor CI + Integration + Review Production major Migration plan + Full regression + Human review Bu sınıflandırma InoviqLab önerisidir.

Lockfile değişikliğini review etmeli miyiz?

Evet. Özellikle package manager diff’i: package.json 1 satır package-lock.json 2.400 satır olabilir. 2.400 satırı manuel okumak pratik değildir. Bu nedenle GitHub Dependency Review gibi araçlar dependency graph değişikliğini daha anlaşılır biçimde gösterebilir; direct ve indirect dependency değişikliklerini, vulnerability bilgilerini ve sürümleri gösterebilir. (GitHub Docs) Dependency Review merge gate yapılabilir GitHub’ın dependency-review-action workflow’u PR dependency değişikliklerini tarayıp bilinen vulnerability içeren yeni dependency olduğunda hata verebilir. Workflow required check yapılırsa bu tür PR’ların merge edilmesi bloklanabilir. (GitHub Docs) Örnek: name: Dependency Review on: pull_request: branches:

• main

permissions: contents: read jobs: dependency-review: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v6
• uses: actions/dependency-review-action@v4

GitHub’ın güncel dokümantasyonundaki örnekte actions/checkout@v6 ve dependency-review-action@v4 kullanılıyor. (GitHub Docs)

npm audit fix kullanmak doğru mu?

Evet, ama sonucu anlamak gerekir. Güncel npm dokümantasyonuna göre:

npm audit

vulnerability’leri raporlar.

npm audit fix

uygun remediation’ları dependency tree’ye uygulayabilir.

Ancak bazı vulnerability’ler otomatik çözülemez ve manuel review gerektirir. (npm Belgeleri)

npm audit fix --force neden dikkatli kullanılmalı?

Çünkü npm:

npm audit fix --force

komutunun top-level dependency’lerde SemVer-major update uygulayabileceğini açıkça belirtiyor. Ayrıca --force, npm’in çeşitli korumalarını devre dışı bırakır. (npm Belgeleri) Dolayısıyla production repository’de: CI kırmızı ↓

npm audit fix --force

↓

commit

↓ merge yaklaşımı güvenli bir otomasyon değildir. Daha doğru: audit ↓ remediation plan ↓ dependency diff ↓ tests ↓ review olmalıdır.

Bir security warning'i yalnızca severity ile değerlendirmek yeterli mi?

Hayır. Örneğin: Critical CVE bulunan dependency: yalnızca build-time tool olabilir. Başka bir: High vulnerability internet-facing authentication request path üzerinde olabilir. Değerlendirme: Severity + Reachability + Exposure + Privileges + Exploitability üzerinden yapılmalıdır. Ama severity düşük diye vulnerability’yi süresiz ignore etmek de doğru değildir.

Transitive dependency vulnerability'si ne olacak?

Uygulama:

A ↓ B ↓ C kullanıyor. Vulnerability: C içinde olabilir. Siz C’yi package.json içinde hiç görmeyebilirsiniz.

npm audit meta-vulnerability hesaplamasında bir direct dependency’nin vulnerable transitive dependency range’i nedeniyle dolaylı olarak vulnerable hale gelebileceğini hesaba katıyor. (npm Belgeleri)

Bu nedenle yalnızca direct dependency listesine bakmak yeterli değildir.

Override/resolution ile transitive dependency zorlamak doğru mu?

Bazen geçici remediation olabilir. Ancak şu risk vardır: Parent dependency ↓ C v1 bekliyor Siz ↓ C v2 zorluyorsunuz runtime compatibility bozulabilir. Override: güvenlik fix’i için geçici köprü olabilir. Ama upstream dependency güncellemesi geldiğinde normal dependency graph’a dönmek tercih edilir.

Update geldikten sonra neyi test etmeliyiz?

Her dependency için

install

type-check

lint unit test production build Runtime dependency Ek olarak: integration test smoke test Framework Ek olarak: SSR/CSR routing build deployment critical E2E Database/ORM Ek olarak: query migration transaction connection behavior Authentication Ek olarak: login/logout authorization session/token negative access tests Payment Ek olarak: payment webhook idempotency refund Dependency update pipeline örneği

Update detected

↓

Security mi?

├─ Evet → Security priority lane

└─ Hayır

↓

SemVer?

├─ Patch → Fast lane

├─ Minor → Standard lane ├─ Major → Migration lane └─ Pre-release → Manual lane Sonra: ↓ Lockfile review ↓ Dependency Review ↓

npm ci

↓ Type-check ↓ Tests ↓ Build ↓ Human/automatic decision ↓ Deploy ↓

Monitor

Auto-merge için hangi dependency'ler uygun?

İyi adaylar:

• güvenilir publisher,
• güçlü SemVer geçmişi,
• patch/minor,
• dev dependency,
• düşük criticality,

güçlü CI coverage. Kötü adaylar:

• auth,
• payment,
• database driver,
• ORM,
• framework major,
• build infrastructure,
• package manager,

runtime. Bu ayrım mutlak değildir.

Publisher güvenilirliği neden önemli?

SemVer kuralları ancak package maintainer düzgün uygularsa faydalıdır. Ayrıca supply-chain riskinde dependency update yalnızca bug riskinden ibaret değildir. Yeni sürüm:

• yeni maintainer,
• yeni install script,
• yeni transitive dependency,

farklı license getirebilir. GitHub Dependency Review yeni veya değişen dependency’lerde release age, kullanım ve license gibi ek bilgiler de gösterebiliyor. (GitHub Docs) Yeni dependency eklemek, update etmekten daha yüksek riskli olabilir Örneğin: existing-lib 2.2 → 2.3 ile: new-awesome-lib 1.0 aynı şey değildir. Yeni dependency:

• yeni supply-chain boundary,
• yeni transitive tree,
• yeni license,

yeni maintainer trust demektir. Bu nedenle dependency review policy: New dependency için daha sıkı olabilir. Dependency sayısını azaltmak da güvenlik stratejisidir Şu yaklaşım: Her problem → yeni npm package uzun vadede:

• vulnerability surface,
• maintenance,
• bundle,

upgrade maliyetini büyütür.

Yeni dependency eklemeden önce:

• 15 satırlık güvenli kodla çözebilir miyiz?

sorusu bazen değerlidir. Ancak cryptography veya security-critical implementation’ı sırf dependency azaltmak için kendiniz yazmak tersine risk yaratabilir.

Güncellemeleri ne sıklıkta yapmalıyız?

Tek evrensel zaman aralığı yoktur. Çoğu aktif web/SaaS repository için örneğin: Security → alert geldiğinde Patch / Minor → haftalık Major → aylık veya planlı bakım döngüsü gibi cadence düşünülebilir. GitHub Dependabot version update konfigürasyonunda daily, weekly gibi schedule’larla otomatik kontrol yapılabilir; temel örneğinde haftalık tarama gösteriliyor. (GitHub Docs) Bu süreler InoviqLab operasyon önerisidir, zorunlu standart değildir.

Güncellemeleri uzun süre biriktirmek neden kötü?

Şu fark:

10 küçük PR ile: 6 ay sonra 48 dependency update arasında debugging açısından büyüktür. Küçük ve sürekli update:

• regression kaynağını izole eder,
• migration maliyetini küçültür,

security debt’i azaltır. Bu nedenle: dependency bakımını yıllık temizlik değil, sürekli bakım süreci olarak görün.

Lockfile'ı commit etmemek doğru mu?

Application projelerinde çoğunlukla hayır.

npm package-lock.json dosyasının tam dependency tree’yi sabitlemek, ekiplerin, deployment’ların ve CI’ın aynı dependency’leri kurmasını sağlamak için source repository’ye commit edilmek üzere tasarlandığını belirtiyor. (npm Belgeleri)

Package/library publishing senaryolarında dependency range stratejisi ayrıca düşünülmelidir.

package-lock.json varken hâlâ update alabilir miyim?

Evet. Lockfile’ın görevi: mevcut çözülmüş tree'yi sabitlemek tir. Dependabot veya developer intentional update yaptığında lockfile yeni dependency tree ile yeniden üretilir. Bu kontrollü değişikliktir.

Dependency update rollback nasıl olmalı?

Dependency PR ayrı tutulursa rollback kolaydır:

Update PR

↓ Production regression ↓ Revert PR Ama aynı PR içinde: 20 dependency update + feature + refactor varsa rollback zorlaşır. Bu nedenle dependency bakım PR’larını mümkün olduğunca feature geliştirmeden ayırmak faydalıdır. Dependency Update Risk Matrisi Güncelleme Risk Merge politikası Dev patch Düşük CI sonrası auto düşünülebilir Dev minor Düşük/Orta CI Runtime patch Orta CI + smoke Runtime minor Orta Integration Auth/payment patch Orta/Yüksek Human review Framework minor Orta Regression Major Yüksek Migration Security patch Risk bazlı acil Hızlı kontrollü Security major Yüksek + acil Hızlandırılmış migration Prerelease Değişken Manual Bu tablo InoviqLab teknik değerlendirmesidir. Dependency Güncelleme Kontrol Listesi

Güncellemeyi tanımla

Security update mi?

Patch/minor/major mı?

Stable mı prerelease mi?

Direct mi transitive mi?

Production mı development dependency mi?

Kaynağı incele

Release notes okundu. Changelog incelendi. Breaking changes kontrol edildi. Migration guide kontrol edildi. Runtime/Node requirement kontrol edildi. Peer dependencies kontrol edildi. Dependency graph package.json diff incelendi. Lockfile değişimi incelendi. Yeni transitive dependencies kontrol edildi. Vulnerability kontrol edildi. Yeni license kontrol edildi. CI

npm ci başarılı.

Type-check başarılı. Lint başarılı. Unit tests başarılı. Build başarılı. Dependency review başarılı. Runtime Integration test yapıldı. Kritik flow smoke test edildi. Browser/server compatibility kontrol edildi. API davranışı değişmedi. Performance regression kontrol edildi. Major upgrade Breaking changes listelendi. Deprecated API’ler kaldırıldı. Migration ayrı PR/plan olarak yürütüldü. Staging doğrulandı. Rollback planı mevcut. Production Monitoring kontrol edildi. Error rate izlendi. Rollback/revert kolay. Dependency PR başka feature’larla karıştırılmadı. InoviqLab teknik değerlendirmesi Bu bölüm InoviqLab değerlendirmesidir; SemVer, npm veya GitHub’ın zorunlu dependency politikası değildir. Dependency yönetiminde iki kötü uç bulunuyor. Uç 1 — Her şeyi otomatik merge etmek

Update geldi

↓ CI yeşil ↓ Merge Özellikle kritik runtime dependency’lerinde fazla agresif olabilir. Uç 2 — Hiçbir şeye dokunmamak Çalışıyor ↓ Güncelleme ↓ Ignore ise:

• security debt,
• EOL,

devasa major migration oluşturur. Dengeli strateji risk bazlı otomasyon olmalıdır. Birinci prensip: Security ile normal maintenance'ı ayır Bir patch release: cosmetic bug fix olabilir. Başka bir major release: kritik RCE fix içerebilir. Bu nedenle: SemVer tek başına priority belirlememelidir. Önce: Security impact kontrol edilmelidir. İkinci prensip: SemVer'i güven olarak değil sinyal olarak kullan PATCH: düşük risk beklentisi oluşturur. Ama: test gereksiz anlamına gelmez. MAJOR: breaking change ihtimali gösterir. Ama:

update edilmemeli

anlamına gelmez. Üçüncü prensip: Daha güçlü CI, daha fazla otomasyon sağlar Bir repository’de yalnızca:

npm run build

çalışıyorsa auto-merge risklidir. Ama: typecheck unit integration E2E dependency review build varsa patch/minor güncellemelerde insan yükü azaltılabilir. Yani: Dependency otomasyon seviyeniz test güveninizden yüksek olmamalıdır. Dördüncü prensip: Major update'i teknik borç olarak takvimlendirin Major PR’ı açıp: 6 ay boyunca bekletmek strateji değildir. PR geldiyse karar verin: Şimdi migrate veya: Q4 migration ve bunun issue/roadmap karşılığını oluşturun. Aksi halde major güncelleme görünmez maintenance debt’e dönüşür. Beşinci prensip: Dependency update'i feature PR'ından ayırın İdeal: PR #1 Dependency update PR #2 Feature Böylece production problemi olursa: dependency revert çok daha kolaydır. Ayrıca code review sırasında değişikliğin gerçek etkisi daha net görülür. Altıncı prensip: Güvenlik için --force çözüm değil

npm audit fix --force bazı durumlarda gerekli remediation’a yardımcı olabilir.

Ama npm’in kendisi bu seçeneğin SemVer-major update uygulayabildiğini ve normal korumaları kaldırdığını belirtiyor. (npm Belgeleri) Dolayısıyla: “Audit temizlendi” ile “uygulama güvenli ve uyumlu” aynı şey değildir.

Sonuç

Dependency güncellemelerinde doğru strateji:

Her update’e aynı davranmak değildir. Semantic Versioning: PATCH → backward-compatible fix beklentisi MINOR → backward-compatible feature beklentisi MAJOR → breaking API change ihtimali verir. (Semantic Versioning) Ancak güvenlik durumu bu sıranın önüne geçebilir. Bu nedenle production dependency yönetiminde güçlü model: SECURITY → priority lane PATCH → fast lane MINOR → standard lane MAJOR → migration lane PRERELEASE → controlled lane şeklinde kurulabilir. Bunu:

• lockfile,
• npm ci,
• dependency review,
• CI,
• Dependabot grouping,
• human review,

production monitoring ile desteklemek dependency bakımını hem daha hızlı hem daha kontrollü hale getirir. (npm Belgeleri) En önemli prensip ise: Dependency güncellemesini “bir paket versiyonu değişti” olarak değil, supply chain’inizde kontrollü bir kod değişikliği olarak değerlendirin.