Bun v1.0.0 - JavaScript ve TypeScript’i çalıştırmak, derlemek, test etmek ve hata ayıklamak için hızlı hepsi bir arada araç seti

• Bun 1.0, JavaScript ve TypeScript’i çalıştırma, derleme, test etme ve hata ayıklama işlemlerini tek bir araçta ele alır; kararlı ve üretime hazır durumdadır
• Node.js alternatifi olmayı hedefleyerek fs, path, net, __dirname, process, node_modules çözümleme gibi Node API’lerini ve modül çözümlemeyi destekler; Express, Koa, Hono ve Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart, Vite tabanlı uygulamalar Bun üzerinde çalışır
• Windows için native build ilk kez sunuluyor ancak son derece deneysel; şu anda yalnızca JavaScript runtime destekleniyor, paket yöneticisi, test runner ve bundler devre dışı
• Bun 0.8’den sonraki değişikliklerle Next.js, Astro, Nest.js desteği eklendi; desteği sonlandırılmış bun dev komutu kaldırıldı ve artık package.json içindeki "dev" script’ini çalıştırıyor
• Yeni desteklenen Node.js API’leri olarak child_process.fork() ve IPC, fs.cp(), fs.cpSync(), fs.watchFile(), fs.unwatchFile(), node:http için Unix socket eklendi
• Runtime’a yerleşik bir JavaScript transpiler dahildir; .js, .ts, .cjs, .mjs, .jsx, .tsx dosyaları ek bağımlılık olmadan çalıştırılabilir
• ESM ve CommonJS’i aynı anda destekler; dosya uzantısı veya package.json içindeki "type": "module" ayarı olmadan aynı dosyada import ve require() kullanılabilir
• fetch, Request, Response, WebSocket, ReadableStream gibi Web standardı API’ler yerleşik gelir; node-fetch ve ws gibi paketler olmadan kullanılabilir
• --hot seçeneğiyle hot reload kullanılabilir; Bun.serve() de hot reload kapsamına girer
• Bun API’leri olarak Bun.file(), Bun.write(), Bun.serve(), bun:sqlite, Bun.password sunulur; dosya G/Ç, HTTP/WebSocket sunucusu, SQLite, bcrypt ve argon2 parola hash’leme ve doğrulama işlemlerini yapar
• Paket yöneticisi bun install, bun add, bun remove, bun update komutlarını sunar; package.json okuyup node_modules içine yazan npm uyumlu bir yaklaşımdır
• Test runner bun:test, Jest uyumlu API sunar; @jest/globals ve vitest import’larını içeride bun:test olarak yeniden eşler
• Bundler, JavaScript ve TypeScript bundle etme ve minify desteği sunar; esbuild uyumlu plugin API’si ve bundle sırasında JavaScript fonksiyonlarını çalıştırıp değerleri inline eden JavaScript macros sağlar

[GN⁺]

Hacker News yorumları

• Bun geliştirmesine katkıda bulunuyorum. Sorularınız varsa yanıtlayabilirim.
  Moderatörün bağlantıyı blog yazısıyla değiştirmesi iyi olurdu. Çünkü açıklaması GitHub sürüm sayfasından daha iyi.
  Blog yazısı: https://bun.sh/blog/bun-v1.0

  • https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0 adresinden değiştirdim.

• Aynı dosyada import ve require() kullanabilmek, .js/.cjs/.mjs ya da "type": "module" ile uğraşmak zorunda kalmamak en etkileyici yanı.
  Bu olmazsa Node.js ekosistemi neredeyse tamamen bozuk sayılır; Bun da bunu kurtarabilecek gibi görünüyor. Bence Bun’daki en müthiş şey performanstan çok Jarred’ın istikrarlı biçimde yaptığı pratik ve geliştirici dostu tercihler.

  • Bu sorun zaten çok eski ve Bun’ın bunu diğer araçlardan daha fazla “çözdüğü” konusunda şüpheliyim.
    Sadece farklı bir ödünleşim seçti; bunun sonucunda da başka bir paket kümesinin çalışmama ihtimali yüksek. Bun’ın, diğer araçların çözemediği bir sırrı çözdüğünü düşünmek için bir dayanak olup olmadığını merak ediyorum.
  • Node söz dizimini ikiye ayırmayı önerdiğinde bu yaklaşımı desteklemesi için bastırmıştım; Bun’ın bunu benimsemesine çok sevindim.
    Bana göre doğru yöntem bu. Node’un bölünmüş ekosistemi dile ve runtime’ın tamamına büyük zarar verdi.
  • Birkaç yılda bir çok JavaScript kullanmam gereken işler çıkıyor; yakın zamanda yeniden içine girince import ile require yüzünden saatlerce uğraştım.
    React uygulaması ya da hazır çözümler kullanmıyorsanız modern JS ekosistemi gerçekten acı verici; küçük kütüphane geliştiren biri için özellikle öyle. Yeni başlayanlar için bunun ne kadar zor ve çıldırtıcı olduğunu hayal bile edemiyorum.
    Bun’ın bu sorunu çözmesi tek başına denemek için yeterli bir neden. Bir başka JS runtime’ı ya da build aracına karşı böyle bir heyecan duyacağımı hiç düşünmezdim; Bun ekibi sayesinde günlerimin biraz daha aklı başında geçebileceğini umuyorum.
  • Yaklaşık 1 yıldır varsayılan olarak modül projeleri oluşturuyorum. TypeScript 5.0’da bundler çözümleme stratejisi çıktıktan sonra son 6 ay genel olarak fena değildi.
    Çok nadiren sorun yaşadım ama projeler düzeltene kadar pnpm patch ve meta düzeltmeleriyle etrafından dolaştım. 2023’e modüllerin yılı denebilir; sular gayet iyi.
  • Katılıyorum. Artık JavaScript uzmanı olmam gerekiyor gibi ama type: module ve .js/.cjs/.mjs/.ts arasında yolumu bulmaya çalışırken hissettiğim kadar aptal hissettiğim başka bir an yok.
    Production uygulamalarında elbette ne kullandığınız net olmalı; ama prototiplemede Bun’ın hoşgörülü davranışı sayesinde önce kodu yazıp gerisini sonra düşünebiliyorsunuz.

• node: tamamını uygulamamış bir 1.0 sürümü için drop-in replacement ifadesinden daha iyi bir ifade kullanılamaz mı diye düşünüyorum.
  İlk denediğim iki projenin drop-in replacement olmaması büyük hayal kırıklığı yarattı ve artık Bun’ın tüm iletişimine şüpheyle bakıyorum.
  Bağlam olarak, iki proje de dgram gerektiren osc kullanıyor. 9 ay önce açılmış özellik isteği takip biletini buldum ama uygulama planı yoktu; bu duyuru sayfasında dgram diye aratınca da hiçbir şey çıkmıyor.
  Hızlı bir öneri olarak, Bun 1.0’da desteklenmeyen modüllerin açıkça belirtilip Node.js uyumluluğu bölümüne konması iyi olurdu.
  Düzenleme: Node destek dokümanını buldum — https://bun.sh/docs/runtime/nodejs-apis . Sürüm notlarında bağlantı verilmesi iyi olurdu.
  Kabaca bakınca modül bazında 17 uygulanmış, 17 kısmen uygulanmış, 7 uygulanmamış gibi görünüyor.

  • Gerçek sürüm 1.0.0 yerine 1.0.0-beta’ya daha yakın görünüyor.
    Az önce v1.0.0’ı kurup bun repl çalıştırdım; çıkış kodu 1 ile başarısız oldu. Meğer REPL 3000 portunu kullanmaya çalışıyormuş ve benim ortamımda bu port zaten kullanılıyormuş. GitHub’da bildirilen hatalara bakınca bu tür küçük sorunların epey fazla olabileceğini düşünüyorum; bu yüzden tüm iddialara bir miktar şüpheyle yaklaşmak gerekebilir.
    Yine de hızından ve ortaya çıkan işten çok etkilendim. Bu projenin bu kadar hızlı buraya geleceğini sanmıyordum; çok daha uzun süreceğini düşünmüştüm. Karşılaştırma yapmak gerekirse Deno çok daha önce başladı ama şu an epey geride kalmış gibi hissettiriyor; kişisel projelerimde Bun’ı denemeyi düşünüyorum.
  • Önemli olan sayı değil, hangi modüller olduğu.
    Anekdot olarak, mevcutta milyonlarca müşterisi olan büyük bir uygulamada Bun’ı deniyoruz; şimdiye kadarki tek sorun Bun’ın kendisi değil, patch-packageın henüz bun.lockb kilit dosyasını desteklememesi oldu.
    Bun tartışmasız biçimde Yarn’dan çok daha hızlı. Bunu Yarn’ı gerçekten seven biri olarak söylüyorum.
  • Node.js uyumluluğu bölümünde zaten şöyle yazıyor:
    “Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.”
    Ayrıntılı listede desteklenmeyen modüller belirtilmiş.
  • Bu yoruma katılıyorum. Gerçekten heyecanlanıp denemek istedim ama projelerimizin çoğunu çalıştıramadı.
    Yanıt ayrıştırma sırasında hata verdiği için AWS SDK v3 kullanamadık; node:crypto tamamen uygulanmadığı için octokit ya da jsonwebtoken bağımlılıklarına sahip şeyleri kullanamadık. jest.resetAllMocks() olmadığı için testleri çalıştıramadık; başka bir projede ise bun test, paylaşımlı kütüphane çağrısının hatalı olduğunu söyleyip hiç başlamadı.
    Bu yüzden yerel çalışma akışımız “Bun ile çalıştırmayı dene, başarısız olursa Node ile yeniden çalıştır” şeklinde. En azından npm yerine kullanılabilir ama hizmet çalıştırmak için kullanmayı şimdilik hayal etmek zor. İyi çalıştığında gerçekten şaşırtıcı olduğu için geleceği heyecan verici; ancak satış noktası Node uyumluluğuysa buna 1.0 demek zor bence.

• Topluluk sohbetini Discord dışındaki bir platforma taşımayı düşünüp düşünmediklerini merak ediyorum
  Discord; erişilebilirlik, gizlilik ve kapalı platforma bağımlılık sorunları nedeniyle HN’de birkaç kez gündeme geldi ve açık kaynak ruhuyla da pek uyumlu görünmüyor. [1] de bakmaya değer
  [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

  • Discord kullanmamak önemli olsa bile bunun değişme olasılığı düşük görünüyor
    Bun 0.6 duyurusunun yorumlarında da benzer bir soru neredeyse flag’lenecek kadar downvote almıştı: https://news.ycombinator.com/item?id=35970869
    Bun 0.8 duyurusunun yorumlarında da aynı soru neredeyse hiç ilgi görmedi; tepki daha çok “diğer projeler de zaten kullanıyor…” düzeyindeydi: https://news.ycombinator.com/item?id=37244294
  • Discord’un erişilebilirliği epey iyileşti. Söz konusu yazının kaynaklar bölümündeki ekran okuyucu kullanıcısı da son dönemde Discord’un erişilebilirliğinin daha iyi hale geldiğini ve daha fazla görme engelli kişinin kullandığını kabul ediyor
    Açıkçası Discord, özgür ve açık kaynak yazılım projelerinin iletişimi barındırması için iyi bir yer. Yazıdaki “Discord’u seçerseniz o platformu meşrulaştırır ve FOSS platformlarından değer çalarsınız” türü iddialar oldukça zayıf görünüyor. Discord gerçekten meşru bir platform; ücretsiz, birçok cazip özelliği var ve erişilebilirliği de iyi. Hepsinden önemlisi, Discord’u seçmek FOSS iletişim platformlarının değerini ortadan kaldırmıyor
    “IRC kullanın” demek de doğru değil. IRC, bilgisayarlara ve yazılıma aşina olmayan pek çok kişi için erişmesi çok zor bir ortam
  • Para gerektirmeyen bir Discord alternatifi FOSS var mı?
  • answeroverflow.com geçici bir çözüm olabilir mi?

• Bun girişim sermayesi destekli; gelir modeli planını merak ediyorum
  Yeni bir teknolojiye bakarken “N yıl sonra da bu teknolojinin aktif olarak geliştiriliyor olma olasılığını” değerlendiriyorum. Bun bir şekilde para kazanmak zorunda; aksi halde fonu kesilir
  Bun lisansının MIT olması harika ve şirket batsa bile projenin ölmeyebileceğine dair umut veriyor. Şirketin başarılı olmasını isterim ama Bun’ı benimsesem ileride ne tür bir üst satışla karşılaşacağımı merak ediyorum

  • İş planı https://oven.sh/ adresinde açıklanıyor
    Oven, backend ve frontend JavaScript uygulamaları için çok hızlı serverless hosting ve sürekli entegrasyon sunacak; Bun ile çalıştırılması planlanıyor
    Next.js, Vite, SvelteKit, SolidStart gibi frontend framework’lerini ve Express, Fastify, NestJS gibi backend framework’lerini desteklemesi planlanıyor
    Dünya genelindeki veri merkezlerinin edge noktalarında kendi sunucularını işletme planı var; Oven, JavaScript stack’inin tamamını donanıma kadar uçtan uca entegre ederek yeni olanaklar yaratmayı amaçlıyor
  • Bir bundler olduğu için bun deploy gibi bir biçimde JS uygulama hosting’inden para kazanacak gibi görünüyor
    Önce geniş ölçekte geliştirici benimsemesi kazanıp sonra kendi uygulama hosting’ine yumuşak biçimde yönlendirmek yaygın bir strateji
  • Eskiden Pundle diye harika bir HMR geliştirme sunucusu vardı. Anında tepki verecek kadar hızlıydı ama aynı zamanda yoksul bir ülkedeki tek bir kişinin sürdürdüğü bir projeydi
    Tek kişinin yan projesini takip etmeye çalışırken o kadar zorlandım ki her şeyi Rollup’a taşıdım ve geriye bakmadım
    Girişim destekli bir projeyle rastgele bir yan projenin kaygıları elbette farklı, ama nihai risk ikisinde de “bunu yapan kişi beni destekleyemezse ne olur?” sorusu
  • NextJS/Vercel ya da Deno/Deploy yoluna gidecek gibi görünüyor; lisans değişikliği olasılığını da dışlamam
    Her şeyi “açık kaynak” diye pazarlayıp ücretsiz bug raporları, katkılar, pazarlama ve benimseme kazandıktan sonra ticari ürüne itme yöntemi bu

• Node tabanlı araçların katman katman birikmiş karmaşasının yerini alabileceği önerisi çok çekici
  Çünkü node, ts-node, nodemon, tsc, jest, ts-jest, webpack, Babel, birbiriyle uyumsuz 2 modül standardı, UMD karmaşası, 3 paket yöneticisi ve bunlar yüzünden patlayarak artan yapılandırma dosyalarının sayısını azaltabilir
  JavaScript etrafındaki araç ekosistemi kesinlikle en büyük acı noktası ve aslında oldukça yetkin ve keyifli bir dil olan ES6 + TypeScript’i tam anlamıyla angaryaya dönüştürüyor. Umarım Bun bunu başarır
  CMake’ten Cargo’ya geçmeye benzer bir his verecek gibi

• Blog yazısı, daha basit bir hepsi bir arada yazılımın değer önermesini çok ikna edici biçimde gösteriyor
  Bu aralar “her şeyi kendin getir” yaklaşımındansa “pilleri dahil” yazılımlar bana daha cazip geliyor; bu yüzden Bun’ı denemek için sabırsızlanıyorum
  Birden fazla yazılımı daha hızlı tek bir şeyle değiştirmeye çalışan Rome araçlarının runtime sürümü gibi hissettiriyor. Rome başarısız oldu ve yeni bir ekibin OSS’ine dönüştü. Bun’ın daha başarılı olmasını umuyorum ama bu kesinlikle çözmesi zor bir problem

  • “Pilleri dahil” yaklaşımına katılıyorum. Zaten Node.js tarafındaki ekosistem uyumlu olsaydı böyle bir yaklaşıma gerek kalmazdı
    Apple gibi donanımı ve işletim sistemini bizzat sahiplenip kontrol ettiğinizde sistemi derinlemesine optimize edebilir, tüm cihazların sorunsuz çalışacağına dair güven de verebilirsiniz. Hepsi bir arada araç seti, mükemmel çözümü bulmak için oradan oraya koşma yükünü azaltır ve zaten gözünüzün önünde duran çözümü kullanmanızı sağlar

• Bun ve Deno’nun ikisini de kullanmış birinden, pratikte hangisinin daha ikna edici bir Node halefi olduğunu duymak isterim
  Bun web sitesi Deno’dan çok daha iyi performans sunduğunu iddia ediyor; bunun gerçekten böyle olup olmadığını merak ediyorum. Öyleyse nedenini de bilmek isterim. Deno’nun da benzer hedefleri var gibi görünüyor
  İki proje arasında büyük felsefi farklar olup olmadığını da merak ediyorum. Örneğin Bun’un her şeyi yeniden uygulamaya çalıştığı, Deno’nun ise Node sonrası yeni bir yol istediği gibi mi, emin değilim. İkisini de yeterince kullanmış biri var mı?

  • İkisi de beni aşırı cezbetmiyor ama en başta neden bir Node halefine ihtiyaç duyulduğunu merak ediyorum
    Bun ve Deno’nun ikisi de girişim sermayesi destekli araçlar olduğu için para kazanma ve sürdürülebilirlik konusunda temel şüphelerim var
    Bun’un ana satış noktası performans gibi görünüyor; ama Node’da pek büyük performans sorunları yaşamadım. Aşırı hızlı değil, ama Node’un hızından önce G/Ç kısıtlarına takılma ihtimali çok daha yüksek
    Deno’nun ana satış noktası, daha iyi paketleme, ES6’nın tam kullanımı vb. birçok açıdan “doğru yapılmış Node” olmasıydı ve bu iddia bana çekici gelmişti; ama yeni bir ekosistem kurma girişiminden vazgeçip Node uyumluluğu eklemeye yönelmiş gibi görünüyor
    Aynı zamanda Node’un kendi test çalıştırıcısı ve yerleşik .env desteği gibi son iyileştirmeleri umut verici. Bu yüzden Bun ya da Deno kullanmak için güçlü bir neden bulmak zor; değiştirsem bile yeni nesil araçlar sürdürülemez hâle geldiğinde Node’a geri dönmek için somut bir yola ihtiyacım var
  • Bu araçlar çok genç; birinin onları gerçekten uzun süre kullandığını söylemek zor
    Bun her şeyi bir araya getirip çok hızlı yaparken, mümkün olduğunca Node ile uyumluluğu korumaya çalışıyor. Mevcut ekosistemi terk etmiyor
    Deno, Node ekosistemine karşı fazla zıt bir bakış açısı benimsedi ve şimdi tekrar destek ekliyor
    Halef açısından Bun’un tek seçenek olduğunu düşünüyorum. Çünkü Node uyumluluğunu korurken yeni özelliklerle yenilik yapmaya çalışıyor
  • Uzman kullanıcı değilim; daha çok Deno ile uğraştım
    Deno, güvenliği birinci ilke olarak alan alternatif bir Node runtime’ına daha yakın görünüyor; TypeScript ve JSX için yerleşik destek, linter gibi araçlar da içeriyor. Ayrıca V8 tabanlı. Gecikmeli olarak Ryan Dahl’ın Node’un böyle olması gerektiğini düşündüğü biçime yakın görünüyor
    Bun teknik olarak WebKit tabanlı; tam olarak nedenini bilmiyorum, ama yalnızca bir runtime değil, daha iyi bir hepsi bir arada araç gibi görünüyor. Mevcut framework’lerle de varsayılan uyumluluk sağlıyor. Deno yakın zamana kadar npm uyumlu değildi; bunun en baştan niyet edilen şey mi, yoksa sürmekte olan bir yön değişikliği mi olduğunu da merak ediyorum
  • Biz full-stack TypeScript ekibiyiz; yaklaşık 50 dahili kütüphane ve yaklaşık 500 bin satır TypeScript yönetiyoruz
    Geçen ay alternatif runtime olarak hem Deno’yu hem Bun’u denedik. Özetle, belli ölçüde karmaşık bir kod tabanında Bun neredeyse her zaman çalışıyor, Deno ise neredeyse hiçbir zaman çalışmıyor
    Şu anda tüm testleri hem Node.js hem de Bun üzerinde çalıştırıyoruz; Deno’yu uygulama girişiminden vazgeçtik
  • Doğru hatırlıyorsam Bun, Node/Deno’dan farklı olarak Windows’u desteklemiyor
    Düzenleme: Değişiyor gibi görünüyor. Düzeltme için teşekkürler

• Aslında dün yayımlanması planlanmıştı, ancak düzeltilmesi gereken bir fetch() gövde akışı testi hatası vardı
  Blog yazısının Bun 1.0 GitHub’a yüklenene kadar herkese açılması planlanmıyordu; ama bağlantı herkese açık erişilebilirdi ve RSS beslemesinde taslağı gizleyemeyen bir hata vardı
  Asıl hata fetch() gövde akışı değil, özelliği tanımlı olmayabilecek bir nesneden özellik alan JavaScriptCore binding tarafındaydı. Kodun bir kısmı değerin nesne olup olmadığını kontrol etmeden yalnızca JSCell olup olmadığına bakıyordu; JSCell genelde nesnedir, ama symbol ya da BigInt gibi şeyler JSObject değildir
  Dünkü konu: https://news.ycombinator.com/item?id=37424724

  • Linux belgelerindeki kurulum bölümünde DEB/RPM eksik; güncellerseniz iyi olur
    Ek bir ipucu olarak, “dağıtım deposundan değil internetten indirme” tarzı kurulumlar için uygun SHA-256 gibi checksum içeren Ansible playbook/task seti örnekleri sunabilirsiniz. Puppet için de aynı şey geçerli, ama biraz daha karmaşık olur
    Sistem yöneticilerinin işini biraz azaltabilir; bir ad vermek isterseniz SAX, yani Sistem Yöneticisi Deneyimi diyebilirsiniz

• Bun, TypeScript React uygulamalarını yerleşik olarak çalıştırıp bundle edebiliyorsa, bunun üstüne Vite.js kullanmanın ne avantajı olduğunu merak ediyorum
  Resmî sitedeki kılavuz, TypeScript React uygulaması oluştururken Bun + Vite.js kullanmayı gösterdiği için kafa karıştırıcı. [1]
  GitHub’da da bununla ilgili bir issue var. [2]
  Vite.js, Bun’ın ele alamadığı daha karmaşık senaryoları veya ileri düzey kullanım durumlarını mı üstleniyor? Benim Vite.js kullanımım temel bir TS+React ayarıyla başlayıp build almaktan ibaret, bu yüzden bir şeyleri kaçırıyor olabilirim
  [1] https://bun.sh/guides/ecosystem/vite
  [2] https://github.com/oven-sh/bun/issues/250

  • Vite, doğrudan kendi sorumluluğunda olmayan kısımlarda hâlâ Node, esbuild, swc, tsc vb. araçlardan yararlanıyor
    Henüz Bun’ı kullanmışlığım yok, ama anladığım kadarıyla yerel geliştirme sunucusunu çalıştırmak için Node yerine Bun’ı; bundle işlemleri için esbuild, tsc, Rollup ya da bunların kombinasyonları yerine Bun’ı; dönüşümler için de Babel ve TypeScript yerine Bun’ı kullanmak mümkün
    Vite’ın sunduğu şey, frontend uygulama geliştirmeyi kolayca yapılandıran ve yerel çalışma sırasında iyi bir geliştirici deneyimi sağlayan bir kurulum
  • Bun ile Vite’ın birlikte kullanılmasını yalnızca HMR amacıyla gördüm
    Şimdilik yapılandırma karmaşıklığı olduğu için ikisini birleştirmenin çok iyi bir fikir olduğunu düşünmüyorum
  • İnsanlardan tüm ekosistemi tek seferde benimsemelerini istemek büyük bir yük
    Mevcut ekosistemle uyumluluk Bun’ın temel hedeflerinden biri; amaç, insanların mevcut codebase’lerinde hemen kullanmaya başlayabilmesi ve zamanla daha fazla alana kademeli olarak dahil edebilmesi
  • Vite’ın plugin ekosisteminden yararlanılabilir gibi görünüyor. PostCSS, Tailwind, Terser gibi şeyler
    Ayrıca Nuxt, SvelteKit, Astro, SolidStart, Qwik gibi yeni meta framework’lerin çoğu Vite üzerinde çalıştığından, Bun için bir benimseme yolu açılabilir
  • Bu, tsc varken neden Vite’a ihtiyaç var diye sormaya benziyor
    Bun’ın “TypeScript React uygulamalarını çalıştırması”ndan ziyade, JSX/TSX dönüşümünü yerleşik olarak sunması gibi görüyorum