SPFx Nisan 2026 Yol Haritası: Sahadan İlk Yorumlar

Geçen hafta bir müşteride, klasik bir SharePoint Online intranet projesinin “Copilot ile zenginleştirilmesi” konusunu konuşuyorduk. Toplantı bitti, ben arabaya bindim, telefonu açtım — bir de bakıyorum Vesa Juvonen Nişan yol haritası güncellemesini yayınlamış. Hani bazen tam zamanında düşer ya haber, işte öyle oldu. Müşterinin sorduğu “SPFx tarafı bu işin neresinde kalıyor?” sorusuna o gün verecek daha taze cevaplarım oluştu.

Şimdi gelin lafı uzatmadan, Microsoft’un Nişan 2026 SPFx yol haritası güncellemesini sahadan bir gözle baştan sona açayım. Yalnız bu sefer birebir özet geçmeyeceğim — daha çok “bu bizim için ne anlama geliyor, Türkiye’deki kurumsal projelerde nasıl konumlanır” tarafına gireceğim. Kısacası, resmî metni çevirmekten çok biraz yorumlayacağım.

Önce büyük resim: SPFx hâlâ neden önemli?

Kendi deneyimimden konuşuyorum, Açık konuşayım: Son 2-3 yıldır SPFx’in “oldu mü, ölmedi mi” tartışması bitmedi. Power Platform geldi, Teams Toolkit geldi, ardından Copilot extensibility geldi. Bu kadar opsiyonun ortasında SPFx’in yeri ne olacak diye merak edenler hâlâ var. Bazı müşterilerde gerçekten bu soruyu net cevaplamak zorunda kalıyoruz. Peki neden?

Bunu biraz açayım.

Vesa’nın Nişan güncellemesi tam da bu konuda iyi bir sinyal veriyor aslında. SPFx, sadece “klasik web part yazma aracı” olmaktan çıkıyor — yavaş yavaş Microsoft 365 extensibility’sinin ortak omurgası hâline geliyor. Teams uygulamaları, Viva Connections kartları, SharePoint sayfaları, hatta yakında Copilot tarafında devreye girecek bazı senaryolar… hepsi aynı framework üstünde gidiyor gibi duruyor. Biraz garip ama mantıklı.

Açıkçası, Bunu Türkiye’deki şirketler açısından değerlendirirsek: Kurumsal müşterilerimde gördüğüm tablo şu — büyük finans, telekom ve enerji şirketleri SPFx’e yatırım yapmış durumda. Yıllardır biriken kod tabanları var, ekipler eğitilmiş, DevOps pipeline’ları kurulmuş. Bunları “artık Power Apps’e geçin” diyerek bir gecede atmak gerçekçi değil (eh, fena değil). Microsoft’un da bunu fark edip SPFx’i Copilot dünyasına bütünleşik etmesi bence stratejik olarak doğru hamle.

SPFx 1.23 release candidate: Beklenenden geç, ama hak ediyor

İşin aslı şu ki, 1.23 sürümü orijinal plandan biraz gecikti (şaşırtıcı ama gerçek). Vesa bunu açıkça yazmış: kalite konusunda taviz — itiraz edebilirsiniz tabi — vermemek için. Özellikle npm tarafındaki audit uyarılarını temizlemek için ek vakit alındı. Ben buna sevindim açıkçası. Çünkü aceleye gelen sürüm sonra baş ağrıtıyor.

Neden? Geçen yıl bir bankacılık projesinde, SPFx 1.18’den 1.19’a geçişte tam üç hafta npm vulnerability listesi ile uğraşmıştım. Müşterinin bilgi güvenliği ekibi haftalık tarama yapıyor, her uyarıda CISO’ya rapor gidiyor; yani iş sadece kod değil, biraz da politika işi oluyor orada. O dönem aldığım ders şu oldu: SPFx’in altında yatan npm bağımlılıkları temiz çıkmazsa, geliştirici ne yaparsa yapsın enterprise’da kapı kapanıyor (şaşırtıcı ama gerçek)

Bir dakika — bununla bitmedi.

1.23 RC’de neler var, kısa kısa:

• List view command set’ler için grouping desteği — küçük gibi duruyor ama gerçekten işe yarayan bir özellik. Komut çubuğundaki butonları gruplayabiliyorsunuz, ayrı menülere koyabiliyorsunuz. (bence en önemlisi)
• Yeni SPFx CLI preview — şablonların açık kaynak hâle getirilmesi var. Bu beni en çok heyecanlandıran kısım, birazdan değineceğim. — ciddi fark yaratıyor
• npm audit temizliği — yukarıda anlattım, enterprise için kritik.

Yeni SPFx CLI ve açık kaynak şablonlar

Bu konuya ayrı bir başlık açtım çünkü gerçekten önemli buluyorum. Yıllardır Yeoman generator ile yola devam ediyorduk. Yeoman fena değil ama bayağı eskidi — Node ekosisteminde artık kimse Yeoman ile yeni proje başlatmıyor desek çok da yanlış olmaz sanırım. Yeni nesil bir CLI gelmesi şarttı.

Tuhaf ama, Açık kaynak şablonlar işe daha da kritik. Çünkü artık ekipler kendi internal şablonlarını rahatça türetebilecek. Logosoft’ta biz de uzun zamandır müşterilere özel başlangıç şablonları (theme, telemetry, ortak component’ler dahil) tutuyorduk — bunları Yeoman generator’ın içine zorla sıkıştırıyorduk ve bazen işler gereksiz yere dolaşıyordu. Yeni CLI ile bu iş çok daha temiz olacak gibi.

“Açık kaynak şablonlar, kurumsal SPFx ekipleri için aslında bir DevEx (developer experience) değişimi gibi duruyor artık.”

SPFx 1.24’teki AI sürprizi: Public preview yolda

Şimdi en ilginç kısma geldik hani… Vesa, 1.24 ile birlikte yeni bir AI odaklı özelliğin public preview’a çıkacağını söylüyor ama detay vermiyor yine de ipucu bırakıyor; sadece şunu söylüyor: “Geliştiricilerin daha akıllı ve yardımcı deneyimler kurabilmesi için tasarlanmış.”

İlginç olan şu ki, Bu cümleyi okuduğumda kafamda iki ihtimal canlandı; tahmin yürüteyim — bunlar resmî bilgi değil, büyük ölçüde benim okumam: Bu konuyla ilgili Visual Studio Nisan Güncellemesi: Cloud Agent Devri Başladı yazımıza da göz atmanızı tavsiye ederim.

1. Copilot extensibility için SPFx tabanlı declarative agent ya da plugin desteği. Yani SPFx solution’ı içinden Copilot agent’larını paketleyebileceğiniz bir yapı olabilir belki de hemen oraya gidiyoruzdur diye düşündüm; çok mantıklı çünkü zaten Teams Toolkit tarafında benzer şey var ve SharePoint developer’ları için de aynı kapıyı açmak gerekiyor.
2. SharePoint sayfalarında AI-driven web part’lar için bir runtime / framework. Yani SPFx web part’ından doğrudan tenant’taki Copilot orchestration’a bağlanabilmek ya da grounding data’yı SharePoint listelerinden çekmek gibi senaryoların önü açılabilir.

%100 emin değilim hangisi olacak; hatta belki ikisi birden gelir veya üçüncü bir şey çıkar bilemem ama mesaj net: SPFx, Copilot dünyasının içine resmen dahil ediliyor.

Peki Türkiye’de bu bize ne kazandırır?

Bakın şimdi bunu gerçek hayata indireyim.. Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de Copilot extensibility tarafının benimsenmesi biraz yavaş ilerliyor; sebebi de basit aslında: lisans maliyeti TL bazında yüksek kalıyor, KOBİ’lerde Copilot for M365 yaygınlaşmadı ve sadece bazı büyük gruplarda var denebilir.. Yani teknolojiyi konuşuyoruz ama saha hâlâ çekingen davranıyor. Service Bus Per-Message Settlement: Batch Derdine Son yazımızda bu konuya da değinmiştik.

Gel gelelim… SPFx üzerinden Copilot extensibility kapısının açılması bu denklemi değiştirebilir.. Çünkü: CodeQL 2.25.5 Çıktı: GitHub Actions Taramaları Keskinleşti yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımıza da göz atmanızı tavsiye ederim.

• Zaten SPFx kullanan büyük kurumlarda Copilot adoption’ını entegre etmek daha kolay olacak. (bence en önemlisi)
• Mevcut SPFx ekipleri yeniden eğitilmek zorunda kalmayacak — aynı toolchain içinde kalacaklar gibi duruyor.
• Lisans tarafında Copilot for M365 olmayan tenant’lar bile en azından “AI-assisted” web part’ları içerden API çağrısı ile (Azure OpenAI gibi) deneyebilir..

Tabi kesin detayları görmeden net konuşmak zor.. 1.24 preview çıktığında ben buraya tekrar yazarım — hatta sonraki yazının notunu şimdiden deftere aldım bile.. Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımızda bu konuya da değinmiştik.

Sürüm planlaması: Hangi tenant ne yapsın?

En çok aldığım soru şu: “Aşkın şimdi production’da 1.20 var; 1.23 RC’yi mi bekleyelim yoksa direkt 1.24 mü?”. Buna tek doğru cevap yok elbette; senaryoya göre değişiyor.. Aşağıya kendi pratiğimden kısa bir tablo koyayım: (şaşırtıcı ama gerçek)

Bunu biraz açayım.

Senaryo	Önerim	Neden
Büyük enterprise,,50+ SPFx solution var	1.23 GA bekleyin,,RC’yi sadece dev tenant’ta test edin	Regresyon riski yüksek,,RC production için yeterince olgun değil
Yeni başlayan proje,,kod henüz az	1.23 RC ile başlayın,,GA’ya geçince güncelleyin	.En güncel TypeScript/Node desteğini başından alın				Npm vulnerability uyarıları rapor ediliyor	1.23 RC’ye geçin,,audit temizliği geldi	Güvenlik açığı kapatma önceliği

Bu tablo elbette tek başına yeterli değil. Her tenant’ın kendi yapısı var. Ama genel bir pusula olarak iş görür.

Pratik geçiş rehberi: İlk 3 adım

Diyelim ki ekibinizdesiniz ve “biz de 1.23’e geçelim” dediniz (evet, doğru duydunuz). Hangi sırayla ilerleyeceğinizi şöyle özetleyeyim:

# 1. Mevcut SPFx versiyonunuzu kontrol edin
npm list @microsoft/sp-core-library
# 2. Yeoman generator'ı güncelleyin (yeni CLI gelene kadar geçerli)
npm install @microsoft/generator-sharepoint@latest --global
# 3. Test projesinde upgrade çalıştırın
npm install -g @pnp/cli-microsoft365
m365 spfx project upgrade --output md > upgrade-report.md

Ne yalan söyleyeyim, PnP CLI’nın project upgrade komutu kelimenin tam anlamıyla hayat kurtarıcı. Tek tek paket güncellemekle uğraşmak yerine, size markdown formatında ne yapmanız gerektiğini sıralıyor.2022’de keşfettim bu özelliği; o günden beri her upgrade’de ilk baktığım araç bu oldu, başka yere pek kaymadım açıkçası.

< div class =”ak-infobox”>
💡 Bilgi:SPFx upgrade ‘lerinde Node.js sürümünü mutlaka kontrol edin.