Açık konuşayım: SharePoint Framework’ün olduğünü söyleyenleri ben de yıllardır duyuyorum. Hatta müşteri toplantılarında “Power Platform varken kim SPFx yazar ki?” diye soranlar çıkıyor, ama sahaya inince tablo biraz değişiyor; geçen ay Ankara’da bir kamu kuruluşunda yaptığımız workshop’ta, hâlâ aktif şekilde SPFx ile çözüm üreten 12 kişilik bir ekiple çalıştık ve üstüne Copilot entegrasyonlarını da konuştuk.
Bence, Neyse, Mayıs 2026 itibarıyla SPFx 1.23 General Availability oldu. Vesa Juvonen’in resmî blog yazısı çıktığında ben bir müşteri Teams entegrasyonunun ortasındaydım, o yüzden notları biraz geç toparladım, kusura bakmayın. Ama bu sefer sadece “küçük bir minor version bump” gibi görmemek lazım; alt tarafta ciddi bir yön değişimi var, özellikle AI tarafında.
1.23 ile gerçekten ne değişti?
Şöyle söyleyeyim, İlk okuduğumda ben de “tamam, yine stabilizasyon release’i” dedim. Haksız değildim ama eksik okumuşum, işin aslı orada biraz farklıymış. Detaylara girince üç başlık öne çıkıyor karşımıza.
ListView Command Sets’te gruplama
Bu özelliği görünce ilk tepkim “nihayet!” oldu. Yıllardır bekleniyordu. Bir listeye 7-8 tane custom komut koyduğunuzda kullanıcı UI’da dağılıyor; bizim bir lojistik müşterisinde tam böyleydi, kargo takıp listesinde 11 farklı aksiyon butonu vardı ve eğitim vermek bile ayrı dert ölüyordu (bizzat test ettim). Şimdi bu komutları gruplara ayırabiliyorsunuz, alt menü yapabiliyorsunuz; küçük duruyor ama UX tarafında baya iş görüyor.
Evet.
Yeni SPFx CLI (Preview)
Şunu fark ettim: Asıl ses getirecek kısım burası. Eski yo @microsoft/sharepoint jeneratörünü kullananlar bilir; Yeoman bağımlılığı, Node sürümü uyumsuzlukları, template’lerin durduk yere kırılması… Bunlarla uğraşmak için insanın ekstra sabrı olması gerekiyordu, hatta bazen kariyer planı bile bozuluyordu diyebilirim.
Küçük bir detay: Yeni CLI daha modüler gidiyor, daha açık duruyor ve community-driven template’leri destekliyor. Henüz preview ama denedim; fena değil, hatta beklediğimden iyi tarafa kaymış. İşte basit kullanım:
# Eski yöntem (hâlâ çalışıyor ama miadı doluyor)
yo @microsoft/sharepoint
# Yeni CLI ile (preview)
spfx init --template webpart --name MyAIWidget
spfx add extension --type listViewCommandSetBurada dikkatimi çeken şey şu: template’lerin merkezî bir registry’den çekilebilmesi planlanıyor. Yani kendi şirket içi template’ınızı de yayınlayabileceksiniz. Logosoft’ta biz zaten müşteriler için internal bir scaffolding aracı tutuyorduk; şimdi bunu yeni yapıya taşımayı düşünüyoruz, çünkü açık konuşayım mantıklı duruyor.
Platform kalitesi ve güvenlik
Hani, Bu kısım genelde pazarlama dilinde “stabilite iyileştirmeleri” diye geçer ve insan pek dönüp bakmaz. Ama burada durum biraz başka. Bilhassa dependency injection tarafında bazı breaking-change’ler hazırlanıyor ve 1.23 bunların altyapısını döşüyor; üstüne CSP (Content Security Policy) uyumluluğu da sıkılaştırılmış durumda, bu da kurumsal müşterilerde küçümsenecek şey değil.
Bunu biraz açayım.
“SPFx’i oldu ilan edenler genellikle hiç enterprise SharePoint Online ortamında çalışmamış kişiler. Türkiye’de en az 200+ büyük şirket var ki, intranetlerinin omurgası hâlâ SharePoint — ve onlar Power Apps’le yapılamayacak özelleştirmeleri SPFx ile yapıyor.”
Türkiye perspektifi: Hangi kurum hâlâ SPFx kullanıyor?
Dürüst olmak gerekirse, Peki neden? Çünkü bence en can alıcı yer burası. Microsoft’un kendi bloğunda bu kadar net analiz göremezsiniz. Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazımızda bu konuya da değinmiştik.
Türkiye’de SharePoint Online lisansı olan büyük kurumların yaklaşık %60-70’i hâlâ aktif SPFx çözümleri çalıştırıyor. Bunlar çoğunlukla şöyle gruplara düşüyor:
- Bankalar ve finans: KVKK ve BDDK uyumluluğu yüzünden bazı veri akışlarını dış sistemlere çıkaramıyorlar. Power Automate cloud connector’ları yerine SPFx + Azure Function kombinasyonu tercih ediliyor.
- Kamu kurumları: İç intranetlerin çoğu SharePoint üzerinde dönüyor. Özelleştirme ihtiyacı çok fazla ve SPFx olmadan işi toparlamak zorlaşıyor.
- Holding yapıları: Çok şirketli yapılarda ortak tenant üzerinde her şirkete özel custom web part’lar gerekebiliyor.
- Üretim sektörü: Atölye panolarından gelen verileri SharePoint dashboard’larında gösterme senaryoları sık çıkıyor.
Bir bankacılık müşterimizde geçen yıl Power Apps ile başlayan projeyi 8 ay sonra SPFx’e taşımak zorunda kalmıştık (şaşırtıcı ama gerçek). Sebep performanstı; listede 50.000+ kayıt vardı ve Power Apps Dataverse tarafı belirgin şekilde zorlanıyordu. SPFx + PnPjs ile aynı UI’ı üç haftada yeniden yazdık, response time da dört saniyeden 600ms seviyesine indi. O yüzden “Power Platform her şeyi çözer” cümlesine ben biraz temkinli yaklaşıyorum.
AI ve Copilot tarafı: roadmap’in asıl ilginç kısmı
Vesa’nın yazısında en çok altını çizdiğim cümle şuydu: “AI-powered solutions and intelligent experiences across Microsoft 365.” İlk bakışta pazarlama dili gibi geliyor, biliyorum; ama altında somut bir şey var gibi duruyor.
Önümüzdeki release’lerde SPFx web part’larının içine Copilot extension’larını gömme imkanı geliyor. Yani siz bir web part yazarken içine “bu listede arama yapan bir Copilot agent” yerleştirebileceksiniz. Neden önemli bu? Bunu A2A v1 Geldi: Agent’lar Artık Aynı Dili Konuşuyor yazımdaki agent protokolüyle birlikte düşünürseniz ortaya çıkan tablo şu oluyor: SharePoint sayfaları artık sadece içerik taşıyan yerler olmayacak, agent host’u hâline gelecekler.
Beklediğim kadar mı? Açıkçası hayır
Bi saniye — Burada küçük bir hayal kırıklığını da söyleyeyim. Mayıs roadmap’inde AI tarafında somut bir API ya da örnek bekliyordum; onun yerine daha çok “üzerinde çalışıyoruz” tonunda bir mesaj gördüm. Microsoft Foundry tarafındaki hızla kıyaslayınca — ki Microsoft Foundry Nişan 2026: Sahadan Notlar. Yorum yazımda anlatmıştım — SPFx biraz ağır kalıyor gibi hissediliyor (buna dikkat edin). Anlaşılır aslında, çünkü backwards compatibility yükü fazla; yine de insan biraz daha hızlı olmasını istiyor. Daha fazla bilgi için Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımıza bakabilirsiniz.
SPFx 1.22 vs 1.23: Karar matrisi
“Şimdi mi geçeyim, yoksa 1.24’ü mü bekleyeyim?” diye soran çok oluyor. Kısa bir karşılaştırma bırakayım:
| Kriter | 1.22’de kal | 1.23’e geç |
|---|---|---|
| Production’da kritik çözüm | ✓ Şimdilik bekle | 1-2 ay sonra |
| Yeni proje başlıyor | – | ✓ Direkt 1.23 |
| ListView grouping ihtiyacı var | – | ✓ Zorunlu geçiş |
| Yeni CLI denemek istiyorum | – | ✓ Ama preview, dikkat |
| Eski Yeoman template’lere bağlı | ✓ Geçişi planla | – |
Şöyle söyleyeyim, Bence yeni başlayacak projelerde direkt 1.23 kullanın (buna dikkat edin). Mevcut projeleri işe öyle hop diye değil, 1-2 sprintlik planla migration edin; CI/CD pipeline’larınızı önce test ortamında 1.23 ile koşturun, sonra production’a alın. Daha fazla bilgi için Claude Opus 4.8 GitHub Copilot’ta: Sahadan İlk İzlenimler yazımıza bakabilirsiniz.
Pratik geçiş rehberi: İlk beş adım
Migrasyonda en çok takıldığımız noktaları sıralayayım barı. Bir müşteride 14 farklı SPFx solution vardı, hepsini taşımak tam 3 hafta sürdü; yani iş hafife alınmıyor. Şu sırayla gitmek daha az can yakıyor: Bu konuyla ilgili SQL + AI Workshop’ları: Var Olan Veritabanına AI Ekleme yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımıza da göz atmanızı tavsiye ederim.
- Sıkça Sorulan Sorular
SPFx 1.23’e geçmek için Node.js’in hangi sürümü lazım?
Node.js 22 LTS en iyi seçenek. 20 ile de bir şekilde çalışıyor aslında, ama bazı build script’lerinde uyarılar çıkabiliyor. 18 ve altı hiç desteklenmiyor, o konuda net. Açıkçası geçmeden önce
nvmya da benzeri bir version manager kurmanızı öneririm — hani eski projeleriniz hâlâ Node 18’e bağlı olabilir, ikisini aynı anda yönetmek bayağı kolaylaşıyor.Yeni SPFx CLI’ı production’da kullanabilir mıyım?
Şu an preview’da, yani production için pek önerilmez. Ama yeni başlayan POC projelerinde denemenizi öneririm — bence bu tür erken feedback’ler CLI’ın nereye gideceğini gerçekten şekillendiriyor. Zaten GA olduğunda eski Yeoman jeneratörünü bırakmanız gerekecek, şimdiden alışmaya başlamak fena olmaz.
Ve işler burada ilginçleşiyor.
SPFx çözümleri Power Platform’a kıyasla daha mı pahalı?
Bir şey dikkatimi çekti: Geliştirme aşamasında genelde evet, çünkü uzman developer gerekiyor. Ama runtime. Lisans maliyeti açısından SPFx çok daha hesaplı — özellikle 200+ kullanıcılı kurumlarda bu fark iyice belirginleşiyor. Mesela premium connector ücretlerinden kurtulduğunuz için, 2-3 yıllık TCO hesabına bakınca SPFx genellikle önde çıkıyor. Tecrübeme göre büyük kurumlarda uzun vadeli maliyet hesabını yapmadan karar vermemek lazım.
Mevcut SPFx çözümlerime Copilot entegrasyonu nasıl eklerim?
Şu an tam bir entegrasyon API’sı yok henüz. Ama Microsoft Graph üzerinden Copilot endpoint’lerini çağırabilirsiniz, yani neredeyse tamamen eliniz boş değil. Resmî declarative Copilot extension desteği önümüzdeki release’lerde geliyor. O zamana kadar Azure OpenAI veya Foundry üzerinden custom çözümler kurabilirsiniz — açıkçası bu yol biraz daha zahmetli ama işe yarıyor.
SharePoint Framework gerçekten ölüyor mu?
Hayır. 1.23 GA ve aktif roadmap bunun tam tersini söylüyor (şaşırtıcı ama gerçek). Microsoft 365 ekosisteminde hâlâ en yaygın kullanılan extensibility modeli SPFx. Bence “ölüyor” diyenler genelde Power Platform tarafından gelen ve büyük kurumsal yapılarla pek çalışmamış kişiler. Yatırımınızı 3-5 yıl daha rahatlıkla yapabilirsiniz.
Kaynaklar ve İleri Okuma
Vesa Juvonen — SharePoint Framework Roadmap Update May 2026 (Resmî Blog)
Microsoft Learn — SPFx 1.23 Release Notes
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
