Next.js 16 testi, Browserslist hedeflerinin CSS'i ama modern JavaScript'i şekillendirmediğini gösteriyor

Alessandro Grosselle tarafından dev.to'da paylaşılan bir deney, birçok Next.js geliştiricisinin muhtemelen merak ettiği bir soruyu yanıtlamayı amaçladı: package. dosyasında bir browserslist hedefi ayarlamak gerçekten build çıktısını değiştiriyor mu? Yazar, birbirinden neredeyse aynı üç Next.js 16 projesi oluşturdu, bunları derledi ve sonuçları bayt bayt karşılaştırdı. Kısa versiyon: browserslist, modern JavaScript çıktısı üzerinde neredeyse hiç etkiye sahip değilken CSS'i anlamlı biçimde şekillendiriyor.

Test nasıl yapıldı

Üç proje yalnızca browserslist alanlarıyla farklılaşıyordu. Biri Internet Explorer 11'i, biri Chrome 116'yı (yaklaşık üç yıl önceki sürüm), biri de Chrome 139'u (yaklaşık bir yıl önceki sürüm) hedefliyordu. Her proje, kasıtlı olarak çok çeşitli dil özelliklerini kapsayacak şekilde yazılmış aynı TypeScript fonksiyonunu derledi: ES2021'den mantıksal atama, ES2022'den Array.prototype.at ve Object.hasOwn, ES2020'den optional chaining ve nullish coalescing, structuredClone, ES2024'ten Object.groupBy ve makaleye göre yazım anında gerçek tarayıcılarda henüz yayınlanmamış ES2026 metodu olan Error.isError.

Kurulumlar ayrıca eslint-plugin-compat ve postcss-preset-env içeren bir PostCSS yapılandırması da içeriyordu; test kodu GitHub'da ale-grosselle/nextjs-browserlist-test olarak yayınlandı. Grosselle her projede next build komutunu çalıştırdı ve üretilen bundle'ları karşılaştırdı.

JavaScript: modern hedefler aynı çıktıyı üretiyor

Beklenti, her hedefin yaşına göre ölçeklenen üç farklı çıktıydı. Ortaya çıkan ise iki çıktıydı. IE11 build'i gerçekten ES5 seviyesine düşürülmüştü: arrow function yok, let veya const yok, for...of manuel bir iterator döngüsüne dönüştürülmüş, optional chaining ve mantıksal atama eski sözdizimiyle değiştirilmişti. Yani SWC, burada gerçek bir sözdizimi seviyesinde transpilation yapıyor.

Buna karşılık Chrome 116 ve Chrome 139 build'leri, her modern yapı olduğu gibi bırakılmış halde, birebir aynı çıktıydı. Daha eski ama hâlâ modern bir Chrome sürümü seçmek, üretilen JavaScript üzerinde sıfır etki yarattı.

Makaleye göre açıklama şu: SWC, browserslist'i bir Babel preset-env hattının yapacağı gibi ECMAScript sürümlerinin bir sürekliliğine eşlemiyor. Her hedefi iki kovadan birine indiriyor: IE11 gibi native ES module desteği olmayan tarayıcılar için legacy ve kabaca Chrome 61, Safari 11 veya Firefox 60 sonrası için modern. Test edilen iki Chrome sürümü de modern kovanın ta içinde yer alıyor ve onları ayıracak bir ara kademe yok. Pratikte, browserslist Next.js JavaScript çıktısını yalnızca en eski hedef ES module desteğinden önceye dayandığında etkiliyor.

Legacy build bile runtime açısından güvenli değil

Daha dikkat çekici bir bulgu: IE11 bundle'ı transpile edilmişti ama polyfill eklenmemişti. Çıktı hâlâ doğrudan .at(-1), Object.hasOwn, structuredClone ve Error.isError çağırıyordu; bunların hiçbiri IE11'de yok ve biri henüz hiçbir tarayıcıda mevcut değil. Makaleye göre SWC yalnızca sözdizimini düşürüyor ve browserslist ayarına bakılmaksızın asla API polyfill'i enjekte etmiyor. Legacy tarayıcılarda çökme olmadan çalışmayı gerçekten gerektiren ekipler, kendi polyfill entry point'lerini getirmek zorunda.

CSS asıl hedefleri takip ediyor

CSS daha umut verici bir hikaye anlatıyor; farklar yalnızca IE11 ile diğerleri arasında değil, iki Chrome build'i arasında da görülüyor. Yalnızca IE11 için bir system-ui font stack'i tam bir fallback listesine genişletildi. CSS nesting üç hedefin tamamında düzleştirildi.

Chrome build'lerini fiilen ayıran özellik color-scheme: light dark oldu. Chrome 116 build'i, IE11 build'i gibi, custom property'ler ve bir prefers-color-scheme media query üzerine kurulu bir fallback aldı; Chrome 139 ise düz tanımlamayı korudu. Makale bunu, ilgili desteğin Chrome 123 civarında, iki hedefin tam ortasında gelmiş olmasına bağlıyor.

Bunun nedeni mimari: Turbopack'ın CSS hattı Lightning CSS kullanıyor ve bu, tarayıcı desteği verilerini SWC'nin module desteği ayrımından çok caniuse veya Baseline'a daha yakın biçimde özellik bazında taşıyor. Bununla birlikte CSS'nin kendi boşlukları da var. Statik bir fallback yolu olmayan color-mix(), :has() ve @container gibi özellikler, IE11 dahil her hedefe değiştirilmeden gönderildi.

Neden önemli

Birçok ekip browserslist'i Babel dönemi davranışı bekleyerek ayarlıyor: bir hedef seç, ona göre kırpılmış çıktı al. Bu test, Next.js 16'da bu beklentinin fiilen CSS için geçerli olduğunu ama JavaScript için, hedef ES-module çizgisinin altına düşmedikçe geçerli olmadığını gösteriyor; o durumda bile polyfill olmadan yalnızca sözdizimi düşürülüyor. Pratik çıkarımlar şunlar: Next.js'te browserslist'i öncelikle CSS'e yönelik bir kontrol olarak görmek, hafif eski modern hedeflerin ekstra uyumluluk sağladığını varsaymamak ve legacy tarayıcı desteği bir config dosyası ritüeli değil gerçek bir gereksinimse açıkça polyfill sağlamak.