Derleme araçları ve paketleyiciler, dağınık kodu hızlı, güvenilir web uygulamalarına dönüştürür. Performans, geliştirici deneyimi, önbellekleme ve üretim güvenliği nasıl iyileşir öğrenin.
Derleme araçları, web uygulamanız için bir “montaj hattı” gibidir. İnsanların okuyup yazdığı hâliyle (ayrı dosyalar, modern sözdizimi, düzenli klasörler) yazdığınız kodu alır ve tarayıcıların verimli şekilde indirip çalıştırabileceği dosyalara dönüştürür.
Bir paketleyici (bundler) ise paketlemeye odaklanan özel bir tür derleme aracıdır: import'larınızı izler, uygulamanızın ihtiyaç duyduğu her şeyi toplar ve bir veya daha fazla optimize edilmiş bundle çıktısı üretir.
Günümüzün çoğu modern uygulaması artık tek bir 3cscript3e etiketi değil. Birçok JavaScript modülü, CSS dosyası, resim, font ve üçüncü taraf bağımlılıklarından oluşurlar. Derleme araçları bu girdiler ile son “üretim” çıktısı arasında durur.
Basitçe, şunları yaparlar:
Tipik bir build, /dist (veya benzeri) bir klasör içinde tarayıcıya hazır dosyalar üretir, örneğin:
app.8f3c1c.js gibi hashlenmiş dosya adları (daha iyi önbellekleme ve güvenli sürümler)Bu çıktılar tarayıcının güçlü yönlerine göre tasarlanır: daha az istek, daha küçük veri, öngörülebilir önbellekleme.
Çok küçük, statik bir sayfa—örneğin az miktarda JavaScript içeren bir pazarlama sayfası—gönderiyorsanız, genellikle paketlemeyi atlayıp sade HTML/CSS/JS sunabilirsiniz.
Birden çok modül, npm paketi veya performans açısından hassas yükleme kullanmaya başladığınız anda derleme araçları ve paketleyiciler "iyi olur" seviyesinden pratik bir gerekliliğe dönüşür.
On yıl önce pek çok site birkaç JavaScript dosyasıyla <script> etiketleri yeterli olabiliyordu. Modern web uygulamaları nadiren böyle çalışır. UI'yi yeniden kullanılabilir bileşenler olarak inşa etmeye, üçüncü taraf paketleri import etmeye ve kodu rotalar arasında paylaşmaya başladığınızda, “sadece başka bir dosya ekle” yaklaşımı yönetilebilir olmaktan çıkar. Bir build adımı, modüller yığınına tarayıcının verimli ve tutarlı şekilde yükleyebileceği bir çıktı verir.
Modüller, ihtiyacınız olanı import ile almanıza, dosyaları küçük tutmanıza ve global değişkenlerden kaçınmanıza olanak sağlar. Ancak proje bağımlılık grafiği, tarayıcının çalışma zamanında yönetmek istediğinizden genelde daha büyüktür. Bir build adımı, modüller yığınına tarayıcının verimli şekilde yükleyebileceği çıktıyı üretir.
Routing, durum yönetimi, grafikler, editörler, analizler gibi zengin UI desenleri hem bağımlılık hem de dosya sayısını artırır. Build adımı yoksa script'leri elle sıraya koymak, aynı kütüphanenin birden fazla sürümüyle uğraşmak ve "çok erken yüklendi" hatalarını kovalamak zorunda kalırsınız. Derleme araçları bağımlılık yönetimini otomatikleştirir, böylece uygulama öngörülebilir şekilde başlar.
Takımlar makineler, branch'ler ve CI arasında tekrarlanabilir sonuçlara ihtiyaç duyar. Bir build adımı kodun nasıl dönüştürüleceğini (TypeScript, JSX, modern JavaScript), varlıkların nasıl işleneceğini ve ortamların nasıl yapılandırılacağını kilitler. Bu tekrarlanabilirlik, "bende çalışıyor" sorunlarını azaltır ve sürüm yayınlamayı daha az stresli kılar.
Kullanıcılar yavaş yüklemeleri ve takılmaları fark eder. Daha az kod göndermek artık "sonra optimize ederiz" niteliğinde değil, bir gereksinimdir. Build adımı, üretime hazırlık yaptığınız yerdir: sadece geliştirme yardımcılarını kaldırmak, çıktıyı minimize etmek ve daha akıllı yükleme stratejileri için zemin hazırlamak burada gerçekleşir.
Tarayıcılar JavaScript çalıştırmakta iyidir, ama nasıl geldiğine karşı seçicidir: çok fazla küçük dosya çok fazla ağ işi demektir, büyük dosyalar indirmeyi yavaşlatır ve modern sözdizimi eski cihazlarda çalışmayabilir. Paketleyiciler, uygulamanızı tarayıcıların hızlı ve güvenilir şekilde yükleyebileceği biçimde paketler.
Paketleyici birçok modülü daha az dosyada birleştirerek tarayıcının pazarlık ve indirme zamanını azaltır. HTTP/2 ve HTTP/3 ile bazı yükler azalsa da her dosyanın hâlâ başlıkları, önbellekleme kuralları ve yürütme sırası vardır.
Uygulamada paketleyiciler, uygulamayı başlatacak küçük bir giriş dosyaları seti ve ihtiyaç duyulduğunda yüklenen ek chunk'lar hedefler.
Paketleyiciler tarayıcının indirmesi ve okuması gerekenleri azaltır:
Daha küçük bundle'lar sadece daha hızlı indirilmez, mobil cihazlarda parse ve yürütme de hızlanır.
Paketleyici, daha yeni JavaScript'i desteklemeyen tarayıcılar için transpile edebilir; fakat iyi kurulumlar bunu yalnızca gerekli olduğunda yapar (desteklediğiniz tarayıcı listesine göre). Bu modern tarayıcıları hızlı tutar ve eski tarayıcıları desteklemeye devam eder.
Optimize edilmiş kod okunması zordur. Paketleyiciler source map üreterek hata raporlarının ve stack trace'lerin orijinal dosyalara yönlenmesini sağlar; böylece üretimde okunmamış kod göndermeden sorun tanımlamak çok daha kolay olur.
Bir paketlenmiş uygulama tek bir, her şeyi içeren indirme olmak zorunda değildir. Kod bölme JavaScript'inizi daha küçük chunk'lara ayırır, böylece tarayıcı sadece mevcut ekran için gerekenleri yükler, geri kalanını ise talep üzerine alır. Amaç basit: özellikle yavaş bağlantılarda kullanıcıların daha hızlı yararlı bir şey görmesini sağlamak.
En yaygın yaklaşım rota bazlı bölmedir: her sayfa (veya ana rota) kendi chunk'ını alır. Birisi pazarlama sayfanıza geldiyse, hesap ayarları ekranının maliyetini ödememelidir.
Özellik bazlı bölme, grafik kütüphanesi, zengin metin editörü veya PDF dışa aktarma akışı gibi "bazen" kullanılan fonksiyonlar için kullanışlıdır. Bu chunk'lar yalnızca kullanıcı özelliği tetiklediğinde yüklenir.
Tek bir büyük bundle, tüm import'ların başlangıç noktasına dahil edilmesiyle oluşur. Bu ilk yüklemeyi yavaşlatır ve küçük değişikliklerin kullanıcıların çok fazla kod yeniden indirmesine sebep olma riskini artırır.
Pratik bir kontrol: bir bağımlılık sadece bir rotada veya bir butonun arkasında kullanılıyorsa, ayrı bir chunk adayıdır.
Akıllı yükleme yalnızca "sonra" demek değildir. Yakında kesinlikle lazım olacak kritik chunk'ları preload edebilir, tarayıcı boşta olduğunda olası sonraki chunk'ları prefetch edebilirsiniz. Bu, ilk isteği şişirmeden gezinmenin anlık hissettirmesine yardımcı olur.
Bölme, chunk'lar stabil olduğunda önbellekleme avantajı sağlar: bir özelliği güncellemek idealde sadece onun chunk'ını değiştirir, tüm uygulamayı değil. Ancak ortak kod kötü düzenlenirse birçok chunk aynı anda değişebilir. İyi paketleyiciler ortak modülleri ortak chunk'lara çıkarır ve tahmin edilebilir chunk dosyaları üretir; bu da gereksiz önbellek geçersizlemelerini azaltır.
Tree shaking, import ettiğiniz ama gerçekte kullanmadığınız kodu kaldıran adımdır. Modern ES modülleriyle (import/export) en etkili çalışır; paketleyici hangi export'ların referans aldığını görüp geri kalanını atabilir.
Örnek: bir yardımcı fonk için bir utility kütüphanesini import edersiniz, ama kütüphane onlarca fonksiyon export eder. Tree shaking ile yalnızca referans verilen export'lar final bundle'a girer—tabii kütüphane ve kodunuz tree-shakeable ise.
Pratik ipuçları:
Paketleyiciler deduplikasyona çalışır, ama şu hallerde yine de çoğaltma olabilir:
Lockfile'ınızı denetlemek ve sürümleri hizalamak beklenmedik büyük bundle'lardan korur. Bir başka kural: büyük bir bağımlılık kullanacaksanız gerekçesi olmalı.
Bundle boyutu kontrolü sadece kullanılmayan kodu kaldırmak değil—göndereceğiniz kodu seçmekle ilgili de:
Intl)Tree shaking'in sınırları vardır. Bir modül import edildiğinde çalıştırılan kod (side effect) varsa paketleyici temkinli olmak zorundadır. Ayrıca dikkat edilmesi gerekenler:
Bundle boyutunu bir ürün özelliği gibi ele alın: ölçün, beklenti koyun ve değişiklikleri incelemelerde takip edin.
Hızlı uygulamalar sadece küçük bundle'larla ilgili değildir—ayrıca aynı dosyayı tekrar tekrar indirmemekle de ilgilidir. Derleme araçları, tarayıcıların ve CDN'lerin dosyaları agresifçe önbelleklemesine olanak veren çıktılar üretir; aynı zamanda bir değişikliği yayınladığınızda anında güncelleme sağlar.
Yaygın desen içerik tabanlı hashing'tir: build dosya adlarına içerikten türetilmiş bir hash ekler, örneğin app.3f2c1a.js.
Bu, dosyayı uzun süre cache'lemenize izin verir çünkü URL yalnızca o dosyanın tam içeriğine özgüdür. Dosya değişmezse adı değişmez ve tarayıcı yeniden indirmez.
Diğer tarafı otomatik cache busting'tir. Kodda bir satır değiştiğinde içerik hash'i değişir, çıktı dosya adı değişir. Tarayıcı yeni URL gördüğünde yeni kaynağı çeker—klasik "deploy ettim ama kullanıcılar eski siteyi görüyor" sorununu engeller.
Bu yöntemin en iyi çalışması için giriş HTML'inizin (veya loader dosyanızın) her deployda yeni hashlenmiş dosyaları referanslaması gerekir.
Paketleyiciler uygulama kodunu ve üçüncü taraf vendor kodunu ayırabilir. Kendi kodunuz sık değişirken bağımlılıklarınız nadiren değişiyorsa, stabil bir vendor bundle tekrar gelen ziyaretçilerin kütüphane dosyalarını yeniden kullanmasını sağlar.
İyileştirmek için genelde:
Hashlenmiş varlıklarla CDN'ler statik dosyaları güvenle cache'leyebilir, tarayıcılar onları doğal olarak tutabilir. Sonuç: tekrar eden ziyaretlerde daha hızlı yükleme, daha az veri transferi ve hızlı düzeltmelerde bile öngörülebilir dağıtımlar.
Derleme araçları sadece kullanıcılar için daha küçük bundle üretmez—aynı zamanda geliştiricileri de daha hızlı ve daha emin yapar. İyi bir toolchain "kodu değiştir → sonucu gör" döngüsünü sıkı hale getirir ve bu hız doğrudan kaliteyi etkiler.
Modern dev sunucular her düzenlemede tüm uygulamayı yeniden inşa etmez. Bunun yerine uygulamanın bellekte bir versiyonunu tutarlar ve çalışırken güncellemeleri iterler.
Geri bildirim yavaşsa, insanlar değişiklikleri topluca yapar. Büyük toplu değişiklikler hatanın gerçek nedenini gizler ve kod incelemelerini zorlaştırır. Hızlı rebuild'ler ve anlık tarayıcı güncellemeleri küçük, güvenli değişiklikleri teşvik eder:
Derleme araçları yerel, staging ve üretim için ortam değişkenleri ve ayarların nasıl okunacağını standardize eder. Her geliştiricinin farklı bir kurulumuna güvenmek yerine toolchain hangi değişkenlerin tarayıcıya açılacağını ve hangi bilgilerin gizli kalacağını tanımlar. Bu "bende çalışıyor" sürprizlerini azaltır.
Dev sunucuları genellikle /api/... çağrılarını gerçek bir backend'e veya yereldeki bir servise yönlendiren API proxy'larını destekler—CORS sorunları olmadan. Ayrıca backend hazır olmadan UI akışlarını inşa etmek veya kenar durumları çoğaltmak için endpoint'leri mocklamayı da kolaylaştırır.
JavaScript en fazla dikkat çeken taraf olabilir, ancak CSS ve “statik” dosyalar (resimler, fontlar, SVG'ler) genellikle bir sayfanın düzgün veya sinir bozucu olup olmayacağını belirler. İyi bir build pipeline bunları birinci sınıf vatandaş olarak ele alır: işlenmiş, optimize edilmiş ve öngörülebilir şekilde dağıtılmış olarak sunar.
Paketleyiciler bileşenlerden import edilen CSS'i toplayabilir, sonra bunu Sass gibi ön işlemciler ve Autoprefixer gibi PostCSS eklentilerinden geçirebilir. Bu, yazımı esnek tutarken çıktı CSS'in hedef tarayıcılarda çalışmasını sağlar ve değişkenler, nesting kuralları ve uyumluluk gibi konuları tek bir yerden yönetmeye yardımcı olur.
Tek bir devasa stil dosyası göndermek kolaydır ama ilk paint'i geciktirebilir. Birçok ekip “kritik CSS”i (üst görünüm için gereken minimum stiller) çıkartır ve geri kalanını sonra yükler. Her yerde bunu yapmanız gerekmez—önce en önemli rotalarınızda (ana sayfa, ödeme, pazarlama sayfaları) başlayın ve etkisini ölçün.
Modern toolchain'ler resimleri sıkıştırabilir, birden çok boyut üretebilir ve uygunse formatları dönüştürebilir (örneğin PNG/JPEG -> WebP/AVIF). Fontlar yalnızca kullanılan glyph'leri içerecek şekilde subset edilebilir ve SVG'ler gereksiz metadata'dan temizlenebilir. Build adımında bunu yapmak, her commit'te manuel optimizasyona güvenmekten daha güvenilirdir.
FOUC genelde CSS HTML'den sonra geldiğinde olur. Bunu önlemek sık sık üretimde CSS'i gerçek stil dosyalarına çıkarmak, kritik font'ları preload etmek ve paketleyicinin temel stilleri kazara ertelemediğinden emin olmak demektir. Pipeline doğru yapılandırıldığında kullanıcılar, yavaş bağlantılarda bile hemen stilize edilmiş içeriği görürler.
Modern paketleyiciler sadece dosyaları paketlemez—aynı zamanda kullanıcılara ulaşmadan önce küçük hataları yakalayan kalite kapıları uygulayabilirler. İyi bir pipeline, kod henüz kolayca düzeltilebilirken sorunları yakalar ve müşteri hatalarına dönüşmesini engeller.
Linting (ESLint) ve biçimlendirme (Prettier) tutarsız kodu ve yaygın tuzakları (kullanılmayan değişkenler, kazara global'ler, riskli kalıplar) önler. Tip kontrolü (TypeScript) verinin uygulamanızda nasıl aktığını doğrulayarak takımlarda hızlanırken güven sağlar.
Bu kontrollerin build (veya pre-build) aşamasında çalıştırılması önemlidir; böylece bir pull request, takımın engelleme kurallarına uymayan hatalar içeriyorsa birleştirilemez.
Otomatik testler birer emniyet ağıdır. Unit testler küçük mantık parçalarını doğrular, entegrasyon testleri bileşenler arası kırılmaları yakalar.
Build araçları test komutlarını şu aşamalara bağlayabilir:
Test kapsamınız mükemmel değilse bile var olan testleri tutarlı şekilde çalıştırmak büyük bir kazançtır.
Haykırarak başarısız olan bir build, sessizce bozulan bir uygulamadan iyidir. Build zamanında yakalanan sorunlar şunların önüne geçer:
Paketleyiciler aynı zamanda bir bundle'ın belirlenen bir boyuttan fazla büyümesini engelleyen kontroller koyabilir, böylece performans zaman içinde bozulmaz.
Build artefaktlarını CI'de üretmek (geliştirici laptop'ı yerine) tekrarlanabilirliği artırır. Kontrollerin geçtiği tam artefaktı dağıttığınızda "bende derleyince farklı çıkıyor" sürprizleri azalır.
Pratik yaklaşım: CI lint + typecheck + testleri çalıştırır, sonra üretim build çıktısını artifact olarak üretir. Dağıtım sadece o artefaktı ilerletir—yeniden build yok, tahmin yok.
Üretim hataları sinir bozucudur çünkü kullanıcıların tarayıcılarında çalışan kod sizin yazdığınız kod değildir: bundle'lanmış, minify edilmiş ve bazen chunk'lara bölünmüş haldedir. Source map'ler bu uçurumu kapatır; araçların minify edilmiş stack trace'i orijinal dosyanıza, satır numarasına ve fonksiyon adına çevirmesini sağlar.
Source map, genellikle bir .map dosyası olan, üretilmiş JS/CSS'i orijinal kaynaklara bağlayan bir eşleme dosyasıdır. Source map etkinse, tarayıcı DevTools gerçek modülü ve hatanın satırını gösterebilir, tek paketlenmiş sıkıştırılmış dosya olsa bile.
Source map'ler hata izleme ile birlikte en değerlidir.
Eğer bir hata izleyici kullanıyorsanız, source map'leri CI sırasında yükleyin ki otomatik olarak de-minify edilebilsin. Anahtar nokta sürüm eşleştirmesidir: source map deploy edilmiş varlıkla (aynı build, aynı hash) tam olarak eşleşmelidir. Bu kurulduğunda uyarılar eyleme geçirilebilir olur—"checkout/validate.ts:83'te çökme" gibi, app.3fd1.js:1:9283 yerine.
Kaynak kodu ifşa etmek bir endişe ise .map dosyalarını herkese açık servis etmeyin. Bunun yerine:
Daha güvenilir sürümler için blog/caching-hashing-and-reliable-deployments kaynağına bakabilirsiniz.
Paketleyiciler uygulamanızı daha küçük ve hızlı yapabilir—ama kazançlar ölçülene kadar gerçek sayılmaz. "Daha hızlı hissettiriyor" bir sürüm hâlâ daha fazla JavaScript gönderebilir veya render'ı geciktirebilir. İyi haber: performansı tahmin edilebilir bir kontrol haline getirebilirsiniz, tahmin oyunu yerine.
Çoğu toolchain üretim build'ında neyin yer aldığını gösteren bir bundle analiz raporu (genelde bir treemap) çıkarabilir. Bu rapor sürprizleri ortaya çıkarır:
Büyük bir bloğu gördüğünüzde sonraki aksiyon somut olur: bağımlılığı değiştirin, daha küçük bir giriş noktası import edin veya lazy boundary arkasına taşıyın.
Performans bütçeleri basit hedeflerdir, örneğin "ilk JS gzip 180 KB altında" veya "ana sayfa orta sınıf mobilde 3s içinde etkileşimli olsun". Birkaç metriği iş hedeflerinizle eşleyin, ve bütçeler gerilediğinde build'i başarısız sayın.
Başlangıç için uygun bütçeler:
Laboratuvar kontrolleri sorunları erkenden yakalar, ama gerçek kullanıcı ölçümleri müşterinin deneyimini söyler. Her sürüm sonrası Core Web Vitals'ı izleyin ve dağıtımları notlandırın ki spike'ları değişikliklerle ilişkilendirebilesiniz. Zaten analitik kullanıyorsanız hafif bir Web Vitals raporu ekleyin ve trendleri gözlemleyin.
Bir döngü kurun: analiz raporunu çalıştırın, bir iyileştirme uygulayın, yeniden build alın ve bütçe ile vitallerin doğru yönde hareket ettiğini doğrulayın. Küçük, doğrulanmış değişiklikler büyük ama kanıtlanmamış "optimizasyon sprintleri"nden genelde daha iyidir.
Bir build toolchain seçmek "en iyi paketleyici hangisi" sorusundan çok uygunluk meselesidir: uygulamanız, takımınız ve deploy edeceğiniz yer. Birçok takım için makul bir varsayılan, iyi desteklenen bir paketleyici, sağlam bir geliştirici sunucusu, güçlü bir eklenti ekosistemi ve öngörülebilir üretim çıktısıdır—sonra sadece gerekçe gösterebildiğiniz yerleri özelleştirin.
Değiştirilemeyecek kısıtlarla başlayın:
Yüksek yapılandırılabilir kurulumlar uç durumları (özel varlık pipeline'ları, alışılmadık modül formatları) ele alabilir, ama aynı zamanda hata yüzeyini artırır. Daha basit toolchain'ler konfigürasyon ağırlığını azaltır ve yükseltmeleri kolaylaştırır—ancak kaçış delikleri daha azdır.
İyi kural: ölçülebilir bir ihtiyaç ortaya çıkana kadar konvansiyonları tercih edin (bundle boyutu, build süresi, uyumluluk). Sonra işi birer değişiklikte ilerletin.
Küçük başlayın: yeni toolchain'i tek bir rota/sayfa veya yeni bir paket için devreye alın, sonra genişletin. Temel işleri CI içinde otomatikleştirin (build, test, lint) ve her geliştiricinin aynı yolu takip etmesi için “mutlu yol” komutlarını belgelendirin.
Amacınız araç zincirini ayarlamak için haftalar harcamadan daha hızlı ilerlemekse, barındırılan bir iş akışı birçok build-ve-deploy sürtüşmesini ortadan kaldırabilir. Koder.ai ile ekipler sohbet üzerinden web, backend ve mobil uygulamaları vibe-code yapabilir; platform modern bir stack (frontend için React, backend için Go + PostgreSQL, mobil için Flutter) oluşturur ve dağıtım/barındırma, özel alan adları, kaynak kodu dışa aktarımı ve geri alma anlık görüntüleri gibi pratik sürüm iş akışlarını destekler. Bu, paketleme kavramlarını anlamayı gereksiz kılmaz—ama “fikri” üretime hazır bir build'e dönüştürme yolunu önemli ölçüde kısaltabilir.
İyileştirmeleri ölçmek için bir temel istiyorsanız blog/performance-basics kaynağına bakabilirsiniz. Barındırılan bir iş akışını veya destek seçeneklerini değerlendiriyorsanız plansayfasını inceleyin.
Bir build aracı proje kaynaklarınızı (modüller, TypeScript/JSX, CSS, resimler, fontlar) tarayıcıya hazır çıkışa dönüştürür—genellikle bir /dist klasöründe.
Bir paketleyici (bundler) paketlemeye odaklanmış bir build aracıdır: import grafiğinizi izler ve tarayıcının verimli yükleyebileceği bir veya daha fazla optimize edilmiş bundle/chunk üretir.
Çok küçük siteler, tek bir HTML dosyası ve az miktarda CSS/JS ile karmaşık bağımlılık yoksa genellikle paketlemeyi atlayabilirsiniz.
Birden fazla modül, npm paketi kullanmaya başladığınızda veya minifikasyon, hashing ya da kod bölme gibi performans özelliklerine ihtiyaç duyduğunuzda, build adımı pratik bir varsayılan haline gelir.
Çoğu build, tarayıcı için hazır varlıklar üretir, örneğin:
app.8f3c1c.js)HTTP/2 ve HTTP/3 olsa bile her dosyanın hâlâ başlıkları, önbellekleme kuralları, öncelikleri ve yürütme sırası gibi maliyetleri vardır. Paketleyiciler şunları yaparak optimize eder:
Kod bölme, büyük bir uygulamayı küçük chunk'lara ayırır, böylece kullanıcılar sadece mevcut rota/özellik için gerekenleri indirir.
Yaygın desenler:
Tree shaking, final bundle'dan kullanılmayan export'ları kaldırır. ES modülleri (import/export) ile en iyi sonucu verir.
Pratik adımlar:
Hashlenmiş dosya adları, içeriğe dayalı bir hash içerir, böylece dosya içeriği değişmediği sürece URL değişmez ve uzun süreli önbelleğe izin verilir.
Bunun sağladıkları:
Geliştirme sunucusu, düzenleme yaptığınızda bellekte bir build tutar ve tarayıcıyı günceller.
Sonuç: daha hızlı geri bildirim ve hata ayıklamayı kolaylaştıran sık, küçük değişiklikler.
Build hatları CSS ve varlıkları birinci sınıf kabul eder:
Bu adımlar, her commit'te manuel optimizasyona güvenmekten daha güvenilirdir.
Source map'ler minify edilmiş/bundled çıktıyı orijinal kaynaklarınıza bağlar, böylece üretimdeki stack trace'ler anlamlı olur.
Güvenli üretim akışı:
.map dosyalarını herkese açık servis etmeyin; bunun yerine izleyiciye yükleyin veya gizli map'ler kullanın