Bun, nebo Deno na malém serveru: který runtime zvolit

Pro malou aplikaci na malém serveru zůstává Node.js bezpečnou výchozí volbou, Bun zkus ve chvíli, kdy chceš co nejkratší cestu od souboru v TypeScriptu k běžícímu HTTP serveru, a Deno si vyber, když chceš, aby runtime odmítl dělat věci, o které jsi ho nepožádal. Všechny tři spouštějí stejný druh programu: dlouho běžící proces, který poslouchá na portu a odpovídá na HTTP. Rozdíly, na kterých na hostovaném tarifu záleží, jsou malé a praktické - jak se server spouští, jak se instalují závislosti, jak se zachází s TypeScriptem, jak se jmenuje lockfile a které balíčky z npm tiše selžou. Tento článek projde každý z nich na skutečných příkazech a končí tím, jak se rozhodnout a co zkontrolovat, když aplikace nastartuje, ale nikdo neodpovídá.

Benchmarky tu schválně nenajdeš. Čísla o propustnosti a paměti runtimů závisejí na verzi, zátěži i stroji a většina porovnání na internetu měří hello-world handler, který žádná skutečná aplikace nepřipomíná. Kde na paměti záleží, rada zní: změř si vlastní aplikaci na vlastním tarifu.

Co který runtime je#

Node.js je zavedený hráč. Spouští JavaScript na enginu V8, dodává se s npm a má zdaleka největší zásobu návodů, podporu u hostingů a prověřených knihoven. TypeScript se ve výchozím stavu přímo nespouští: buď ho zkompiluješ, nebo použiješ loader či přepínač, který odstraní typy, a co přesně je podporované, závisí na verzi Node, kterou provozuješ.

Bun je jeden spustitelný soubor, který je zároveň runtime, správce balíčků, nástroj na testy a bundler. Používá engine JavaScriptCore místo V8, snaží se být kompatibilní s API Node i s balíčky z npm a soubory .ts a .tsx spouští přímo. Vlastní serverové API se jmenuje Bun.serve. Správce balíčků je bun install a lockfile je bun.lock.

Deno je runtime postavený na bezpečnostním modelu a webových standardních API. TypeScript spouští přímo, má v sobě formátovač, linter, nástroj na testy a kontrolu typů a kód běží bez přístupu k síti, prostředí nebo souborovému systému, dokud mu je nepovolíš. Serverové API je Deno.serve. Konfigurace je v deno.json a tam se definují i úlohy (tasks).

První věc, kterou je potřeba si ujasnit: nejde o tři příchutě téhož. Sdílejí jazyk a velkou část standardního webového API - fetch, Request, Response, URL, AbortSignal, streamy - a proto se malý handler často dá napsat jednou a přenést mezi nimi. Dál už se rozcházejí a právě v tom rozcházení se ztrácí čas.

Než se na cokoli z tohoto článku spolehneš, zjisti si, jakou verzi vlastně máš. Všechny tři se rychle vyvíjejí a node --version, bun --version a deno --version jsou první řádky každého hlášení chyby.

Server v Bunu#

Nejmenší použitelný server v Bunu je jeden soubor:

const port = Number(process.env.PORT) || 3000;const server = Bun.serve({  port,  hostname: "0.0.0.0",  fetch(req) {    const url = new URL(req.url);    if (url.pathname === "/healthz") {      return Response.json({ ok: true, uptime: process.uptime() });    }    return new Response("hello from bun\n");  },});console.log(`listening on ${server.port}`);

Spustíš ho příkazem bun run server.ts, nebo jen bun server.ts. Handler dostane standardní Request a vrací standardní Response, takže není co instalovat. Routování si píšeš sám, což je v pořádku pro hrstku endpointů a otravné nad tuto hranici. Frameworky postavené na webových standardních požadavcích, například Hono a Elysia, běží na Bunu a jsou obvyklým dalším krokem. Express na Bunu běží také, přes vrstvu kompatibility s Node, s výhradami popsanými v sekci o kompatibilitě níže.

Tři detaily stojí za zapamatování. Za prvé, hostname: "0.0.0.0" je tu napsané kvůli srozumitelnosti; jde o to, že server musí poslouchat na všech rozhraních, protože server navázaný na loopback uvnitř kontejneru není dosažitelný z proxy před ním. Za druhé, Bun automaticky čte soubor .env v pracovním adresáři a proměnné jsou dostupné přes process.env i Bun.env. Lokálně je to pohodlné, na serveru to je past: zapomenutý .env v repozitáři tiše přebije tvůj záměr nebo vyzradí tajemství. Skutečná tajemství drž v prostředí. Za třetí, bun --hot server.ts při vývoji znovu načte kód po změně, což se nehodí pro produkci.

Závislosti přicházejí z bun install. Ten přečte package.json, zapíše node_modules a strom zaznamená do bun.lock. Starší verze Bunu zapisovaly binární soubor bun.lockb; současné verze zapisují textový bun.lock, který se v pull requestu pořádně porovnává. Pokud je v repozitáři starý bun.lockb, zjisti, který z nich tvoje verze Bunu čte, než některý smažeš. Pro deploy je ekvivalentem npm ci tento příkaz:

$ bun install --frozen-lockfile

Nainstaluje přesně to, co říká lockfile, a selže, pokud se package.json a lockfile rozcházejí, ze stejného důvodu, proč existuje npm ci. Přidej --production, aby se přeskočily devDependencies, pokud je tvoje spouštěcí cesta nepotřebuje.

Server v Denu#

Stejný program v Denu:

const port = Number(Deno.env.get("PORT")) || 8000;Deno.serve({ port, hostname: "0.0.0.0" }, (req: Request) => {  const url = new URL(req.url);  if (url.pathname === "/healthz") {    return Response.json({ ok: true });  }  return new Response("hello from deno\n");});

Deno.serve bere objekt s volbami a handler, který je opět funkcí z Request na Response. Výchozí port je 8000, pokud žádný nepředáš, a výchozí hostname poslouchá na všech rozhraních, ale napsat obojí nic nestojí a při pozdějším hledání chyb ubude jedna věc k hádání.

Spuštění je místo, kde se Deno liší nejvíc, kvůli oprávněním:

$ deno run --allow-net --allow-env=PORT main.ts

Bez --allow-net je program odmítnut ve chvíli, kdy se pokusí otevřít socket. Bez --allow-env volání Deno.env.get selže s chybou oprávnění (nebo se zeptá, pokud ho spouštíš interaktivně). Model je „zakázáno ve výchozím stavu“ a pro malý server je opravdu užitečný: závislost, která najednou chce číst tvoje prostředí nebo se někam připojit, skončí chybou místo tichého úspěchu.

Konfigurace projektu patří do deno.json a na hostingu využiješ hlavně část tasks:

{  "tasks": {    "start": "deno run --allow-net --allow-env=PORT,DATABASE_URL main.ts",    "dev": "deno run --watch --allow-net --allow-env main.ts",    "check": "deno check main.ts"  },  "imports": {    "hono": "npm:hono@4"  }}

deno task start spustí příkaz z dané úlohy. Blok imports je import map: dává balíčkům krátká jména, takže v kódu můžeš napsat import { Hono } from "hono". Prefix npm: stáhne balíček z registru npm a jsr: z JSR, vlastního registru Dena. Deno zapisuje soubor deno.lock, který připíná, co stáhlo, a přepínač --frozen způsobí, že instalace nebo spuštění selže, pokud by se lockfile měl změnit. Pokud v projektu pro Deno držíš package.json, současné verze ho čtou a umějí instalovat do node_modules; to je správná cesta, když přenášíš existující projekt z Node místo toho, abys začínal od nuly.

Přepínače oprávnění a co povolit#

Oprávnění jsou hlavní důvod, proč zvolit Deno, a stojí za to je používat pořádně a nesahat po přepínači, který povolí všechno.

Existují další (--allow-run pro spouštění procesů, --allow-ffi, --allow-sys) a -A neboli --allow-all zapne všechno najednou. Pro server, který poslouchá, čte dvě proměnné prostředí a servíruje adresář, je poctivá sada prvních tří přepínačů výše, každý zúžený:

$ deno run \    --allow-net=0.0.0.0:8000,db.internal:5432 \    --allow-env=PORT,DATABASE_URL \    --allow-read=./static \    main.ts

Dvě upozornění. Úzké podoby jsou tak dobré, jak dobrý je tvůj seznam: knihovna přidaná minulý měsíc může potřebovat další proměnnou prostředí a selhání přijde jako chyba oprávnění až při prvním požadavku, který se jí dotkne, ne při startu. Než seznamu uvěříš, projdi aplikaci všemi jejími skutečnými cestami. A -A je legitimní volba pro soukromý nástroj, ale pak ses vzdal funkce, která ten runtime ospravedlňovala, tak k sobě buď upřímný.

Bun ani Node nemají ekvivalentní přepínač. Novější verze Node mají experimentální model oprávnění za přepínačem a jeho stav se mezi vydáními mění, takže si před jeho použitím přečti dokumentaci k verzi, kterou provozuješ.

TypeScript bez build kroku#

Tiché kouzlo Bunu i Dena je, že main.ts běží tak, jak je. Žádný tsc, žádný adresář dist, žádné source mapy, které musíš udržovat v souladu s běžícím procesem, a žádná devDependency na kompilátor, čímž se obejde past tsc: not found popsaná v článku o npm ci. U malé aplikace tím z deploye zmizí celá fáze.

Co dostaneš, se v každém trochu liší:

• Bun transpiluje TypeScript tak, že ho odstraní a transformuje, a typy nekontroluje. Chyba typu program nezastaví; prostě si jí nikdo nevšimne. Chceš-li kontroly, spouštěj tsc --noEmit v CI.
• Deno také ve výchozím stavu spouští soubor přes deno run, aniž by na kontrole trvalo, a pro explicitní kontrolu typů nabízí deno check. Když dáš deno check main.ts do CI nebo do úlohy, získáš záchrannou síť.
• Node umí v nedávných verzích spouštět TypeScript odstraněním typů, s omezeními na to, které vlastnosti TypeScriptu jsou podporované. Pokud na tom stavíš, připni verzi Node a přečti si poznámky k ní.

Praktické pravidlo je všude stejné: spouštět TypeScript neznamená kontrolovat ho. Runtime rád nastartuje program s chybou typu a první, co se dozvíš, je TypeError v logu za běhu. Typy kontroluj v CI nebo před pushem a server ber jako místo, kde program běží, ne kde se ověřuje.

Je tu ještě jeden háček. Vlastnosti TypeScriptu, které potřebují generování kódu, jako jsou starší dekorátory a některá použití enum a namespace, různé nástroje zpracovávají různě. Nastavení v tsconfig.json jako experimentalDecorators nebo paths Bun čte; Deno čte volby kompilátoru z deno.json a má vlastní pohled na rozlišování modulů, včetně požadavku na explicitní přípony souborů v relativních importech. Projekt psaný pro bundler, který rozliší ./utils bez přípony, na Denu selže, dokud importy neříkají ./utils.ts.

Kompatibilita s npm a co se rozbije#

Většina npm funguje na obou. Čistě JavaScriptové balíčky téměř vždy, stejně jako oblíbené frameworky. Selhání se shlukují na několika místech a vyplatí se je znát dřív, než přenášíš existující projekt.

• Nativní doplňky. Balíčky, které při instalaci kompilují C nebo C++ a načítají binárku .node, například některé ovladače pro obrázky, kryptografii a databáze, závisejí na rozhraní nativních doplňků Node. Bun podporuje Node-API pro mnoho z nich a Deno ho podporuje za oprávněním, ale balíček, který sahá do vnitřností V8, se nenačte. Dávej přednost balíčkům, které dodávají WebAssembly nebo mají čistě JavaScriptovou náhradu.
• Instalační skripty. bun install ve výchozím stavu nespouští lifecycle skripty libovolných závislostí; vede si seznam důvěryhodných balíčků a ty přidáváš přes trustedDependencies v package.json. Balíček, který potřebuje postinstall ke stažení binárky (enginy Prismy, prohlížeč Puppeteeru, platformní build sharp v některých konfiguracích), může dorazit bez souboru, který potřebuje. Deno také vyžaduje výslovný souhlas s lifecycle skripty, přepínačem --allow-scripts při instalaci.
• Vestavěné moduly Node na okrajích. Oba runtimy implementují většinu node:fs, node:http, node:crypto, node:stream a dalších a oba se snaží sledovat chování Node. Mezery jsou v zřídka používaných koutech: node:cluster, detaily node:vm, některé chování worker_threads, node:inspector a přesné načasování streamů a událostí. Kód, který závisí na jemném chování, je místo, kde se přenos pokazí.
• Frameworky, které předpokládají serverový objekt Node. Express na Bunu funguje přes kompatibilní vrstvu node:http. Express na Denu funguje přes npm:express se stejnou vrstvou a správnými oprávněními. Obě cesty fungují, ale provozuješ API Node na runtimu, který Node není, a chyba, která se objeví, bude ve švu. Framework postavený na webových standardních Request a Response se švu vyhne úplně.
• Nástroje, které očekávají Node. Cokoli, co volá node přes shell, čte process.versions.node k větvení nebo je zdokumentované jen pro npm run a npx, chce kontrolu. bunx a deno run npm:package nahrazují npx.

Jak to zjistit, je nudné: nainstaluj, spusť aplikaci, zavolej každou routu, pusť testy pod novým runtimem a čti log kvůli varováním. Balíček, který je v changelogu „podporovaný“, může přesto selhat v té jedné cestě kódu, kterou používáš. Pokud je projekt většinou hromada závislostí specifických pro Node, náklady na přechod obvykle převáží, co získáš.

Paměť, start a otázka malého tarifu#

Lidé přecházejí na Bun nebo Deno v naději na nižší spotřebu paměti nebo rychlejší starty. Někdy to dostanou, někdy ne. Tady by byl publikovaný údaj nepoctivý, takže tohle se dá říct bezpečně.

Rezidentní paměť závisí na základní spotřebě enginu, množství načteného kódu, velikosti tvých dat v paměti, zvycích garbage collectoru a alokátoru. Dva runtimy se stejnou aplikací se mohou lišit oběma směry a hodnota v klidu málokdy předpoví hodnotu pod zátěží. JavaScriptCore a V8 sbírají odpad různě a proces, který v klidu vypadá štíhle, může pod určitým vzorem požadavků stejně narůst. Žádný z enginů nezaručuje menší stopu.

Co dělat můžeš, je změřit to, co skutečně budeš provozovat:

1. Spusť aplikaci na tarifu, který zamýšlíš koupit, s realistickou kopií jejích dat.
2. Sleduj graf paměti v konzoli, zatímco přehráváš reprezentativní provoz, včetně největšího požadavku, který tvoje aplikace zpracovává.
3. Nech ji běžet den. Únik paměti vypadá jako čára, která se nikdy nevrátí dolů.
4. Porovnávej s limitem tarifu, ne s číslem z blogu.

Limity paměti se na RE:NODE chovají určitým způsobem: kontejner, který dosáhne limitu, se zastaví a znovu čistě spustí, místo aby swapoval. Důsledek na Bunu a Denu je stejný jako na Node - únik se projeví jako restart každých pár hodin. Tři restarty za hodinu vyvolají varování na stránce serveru a automaticky otevřou ticket. Limity paměti v Node vysvětleně popisuje přepínače haldy ve V8; na Bun se nepřenášejí, ten má vlastní nastavení, takže nevkládej přepínače Node do spouštěcího příkazu Bunu a nečekej, že je bude respektovat.

Doba startu je další tvrzení. TypeScript, který běží přímo, ušetří krok kompilace a instalátor Bunu je rychlý, ale na hostovaném tarifu záleží na tom, jak dlouho trvá deploy od pushe po odpověď, a ten je z největší části tvořen instalací závislostí a tvou vlastní startovací prací, jako jsou připojení k databázi a migrace. Měř deploy, ne hello-world.

Práce s procesem, prostředím a portem#

Pro všechny tři runtimy platí stejná pravidla a jsou to ta, která způsobují většinu tiketů typu „lokálně to funguje“.

Čti port z prostředí. Napevno zadaný port znamená, že aplikace poslouchá někde, kam nic nesměřuje. Na RE:NODE má tarif pro aplikace jednu alokaci portu, zobrazenou na záložce Network, a proměnné prostředí se nastavují na záložce Startup. Použij název proměnné, který ukazuje tvůj tarif, místo hádání, a výchozí hodnotu použij jen pro lokální běh.

Poslouchej na všech rozhraních. 0.0.0.0 v Bun.serve a Deno.serve a ekvivalent v každém frameworku. Server, který zapíše „listening“ na 127.0.0.1 a nic neodpovídá, je nejčastější chyba a způsobuje connection refused z proxy bez jediného řádku ve tvém vlastním logu.

Při chybějící konfiguraci rychle skonči. Vzor z článku o Expressu v produkci platí beze změny:

const required = ["DATABASE_URL", "SESSION_SECRET"];const missing = required.filter((name) => !process.env[name]);if (missing.length) {  console.error(`missing configuration: ${missing.join(", ")}`);  process.exit(1);}

V Denu nahraď process.env[name] výrazem Deno.env.get(name) a pamatuj, že seznam --allow-env musí obsahovat každé jméno, které čteš. Novější verze Dena podporují process.env také přes vrstvu kompatibility s Node, ale čistší je držet se v projektu jednoho stylu. Kam patří tajemství, řeší článek proměnné prostředí a tajemství.

Obsluhuj SIGTERM. Restart nebo deploy pošle ukončovací signál a server, který ho ignoruje, je po odkladové lhůtě zabit a zahodí rozpracované požadavky. V Bunu a Node funguje process.on("SIGTERM", ...) a v Bunu přestaneš přijímat spojení pomocí server.stop(). V Denu použij Deno.addSignalListener("SIGTERM", ...) a server.shutdown() na objektu, který vrací Deno.serve. Obecný postup včetně health endpointů je v článku řádné ukončení a health checky.

Loguj na stdout. Konzole ho zobrazuje bez filtrování a živě. Strukturované řádky JSON stojí za těch pět minut navíc.

Provoz na RE:NODE#

RE:NODE má v kategorii aplikací samostatné řady Bun a Deno, každá od 4 USD měsíčně za 1 GB paměti, 5 GB disku a půl vCPU, s většími úrovněmi výše. Stojí vedle Node.js, Pythonu, Go, Javy, Laravelu a C# a panel je u všech stejný: konzole, správce souborů, SFTP, zálohy a záložka Startup. Tarify a aktuální ceny jsou na stránce hosting aplikací.

Pro tyto dvě řady platí několik specifik:

• Úvodní stránka. Každá řada runtimu kromě Node.js spustí nový server s malou fungující stránkou na jeho adrese, dokud nenasadíš vlastní kód, a nikdy nepřepíše tvoje soubory. Je to rychlý způsob, jak ověřit, že adresa a alokace portu fungují, dřív než se do toho zapojí tvůj kód. Servery s Node.js tuto stránku nemají.
• Deploy z GitHubu. Funkce Git deploy je dostupná na všech řadách aplikací: jen GitHub, přes GitHub App s krátkodobými tokeny, takže fungují i soukromé repozitáře. Ovládají ji dva přepínače - pull při každém startu a deploy při pushi, který restartuje běžící server a spustí zastavený - a každý deploy zanechá záznam. Postup pro Node v článku nasazení aplikace v Node.js z GitHubu se na ostatní řady dá přenést téměř beze změny.
• Proxy slot. Tarify pro aplikace zahrnují proxy slot. Nasměruj A záznam na zobrazenou adresu a certifikát se vystaví a obnovuje automaticky v okně 21 dnů; skutečná adresa klienta přichází v X-Forwarded-For. V Bun.serve a Deno.serve žádné nastavení trust proxy neexistuje, takže hlavičku čti sám a pokud důvěřuješ jednomu přeskoku, vezmi poslední položku. Podrobnosti jsou v článcích co dělá reverzní proxy a nasměrování domény na server.
• Správce procesů není potřeba. Panel restartuje proces, který skončí, takže PM2 ani supervisor nepotřebuješ. Poctivé srovnání je v článku PM2, nebo hostingový panel.
• Sloty pro databáze. Tarify pro aplikace zahrnují dva sloty pro databáze, vytvářené v panelu s vygenerovanými přihlašovacími údaji, které aplikaci předáš jako proměnné prostředí.

Nespoléhej na to, co panel neříká. Tento článek ti nesděluje přesný spouštěcí příkaz nového serveru s Bunem nebo Denem ani to, která proměnná nese port, protože to stojí za to přečíst na vlastní záložce Startup. Úvodní stránku ber jako důkaz, že adresa funguje, a pak ji nahraď.

Instalační a spouštěcí příkazy pro typický deploy jsou krátké:

# Bunbun install --frozen-lockfile && bun run server.ts# Denodeno task start

Volba mezi Node, Bunem a Denem#

Univerzální odpověď neexistuje a následující je úsudek, ne měření.

Vol Node.js, když máš existující aplikaci s hromadou závislostí z npm, když spoléháš na nativní doplňky, když ho tým už zná nebo když chceš co nejméně překvapivé chování. Skoro ke každému problému s nasazením, na který narazíš, už existuje napsaná odpověď pro Node. Cenou je krok kompilace TypeScriptu, který je malý.

Vol Bun, když začínáš novou službu v TypeScriptu, chceš jeden nástroj pro instalaci, spuštění i testy a tvoje závislosti jsou čistý JavaScript nebo je o nich známo, že na Bunu fungují. Je nejblíž náhradě Node bez úprav, protože čte package.json a node_modules, takže vyzkoušení stojí odpoledne, ne přepsání. Než se zavážeš, pusť si pod ním testy.

Vol Deno, když tě láká model oprávnění, když chceš mít deno check, deno fmt a deno lint v balení nebo když píšeš proti webovým standardním API a importuješ z JSR. Hodí se na malé API s málem závislostí. Hůř se hodí na velkou kódovou základnu v Expressu, která nikdy nevznikala s ohledem na oprávnění.

Pokud si nejsi jistý, postav aplikaci na webových standardních Request a Response s malým frameworkem jako Hono, drž závislosti čistě v JavaScriptu a mezi všemi třemi budeš moct přecházet změnou vstupního souboru. Taková přenositelnost má větší cenu než jakýkoli tvrzený rozdíl v rychlosti.

Řešení potíží#

Server nastartuje a nic neodpovídá. Adresa, na které poslouchá, nebo port. Ověř, že host je 0.0.0.0 a port je ten, který tarif přiděluje. Otevři záložku Network, porovnej a podívej se na řádek, který aplikace vypisuje do logu.

`error: Cannot find module` v Bunu po deployi. Instalace neproběhla, nebo proběhla se špatnými přepínači. Dej bun install --frozen-lockfile do spouštěcího příkazu a přečti si výstup v konzoli. Pokud balíček potřebuje krok postinstall, přidej ho do trustedDependencies.

`error: Requires net access` nebo `Requires env access` v Denu. Chybí oprávnění. Chyba pojmenuje oprávnění a často i přesného hosta nebo proměnnou. Přidej úzký přepínač místo -A.

`error: Relative import path "x" not prefixed with / or ./ or ../`. Deno chce buď relativní cestu s příponou, nebo mapování v imports v souboru deno.json. Přidej mapování.

Neshoda lockfile při instalaci. bun install --frozen-lockfile a --frozen v Denu selžou, když se manifest změnil bez lockfile. Vygeneruj ho lokálně, commitni a nasaď. Přepínač na serveru nevynechávej.

Balíček lokálně funguje a na serveru selhává. Volitelné závislosti specifické pro platformu, nativní binárky nebo chybějící postinstall. Lockfile generuj na stroji s Linuxem nebo v CI a v poznámkách balíčku zkontroluj svůj runtime.

Graf paměti stoupá a pak se server restartuje. Únik paměti, neomezená cache nebo velký payload držený v paměti. Přečti si sekci o paměti výše, omez své cache a v konzoli sleduj vzor restartů. Na co se dívat, popisuje čtení konzole.

WebSocket se lokálně připojí a přes proxy spadne. Časové limity nečinnosti a zpracování upgradu v cestě přes proxy. Viz WebSockety za reverzní proxy.

FAQ#

Je Bun připravený na produkci?

Používá ho v produkci mnoho týmů a zároveň je mladší než Node a jeho záznam o kompatibilitě je méně úplný. Jestli je připravený pro tvoji aplikaci, záleží na tvých závislostech. Pusť pod ním testy, zátěžově otestuj routy, na kterých ti záleží, a nech si možnost vrátit se na jedno či dvě vydání k Node.

Mohu provozovat existující aplikaci v Expressu na Bunu nebo Denu?

Obvykle ano, přes vrstvy kompatibility s Node, ale ber to jako migraci s testovacím průchodem, ne jako přepnutí přepínače. V Denu přidáš specifikátory npm: nebo package.json a k tomu oprávnění. Pozor na nativní moduly a na vše, co závisí na vnitřnostech Node.

Potřebuji pro TypeScript build krok?

Na Bunu ani Denu ne, soubory .ts spouštějí přímo. Kontrola typů ti přesto musí běžet někde, protože ani jeden spouštěcí příkaz chybu typu neodmítne. Dej tsc --noEmit nebo deno check do CI.

Co používá méně paměti, Bun, nebo Deno?

Záleží na aplikaci, verzích a zátěži a jakékoli jediné číslo by bylo odhad. Změř si vlastní aplikaci na tarifu, který chceš používat, a porovnej graf s limitem.

Jak se jmenuje lockfile Bunu?

bun.lock, textový soubor, v současných verzích. Starší verze zapisovaly binární bun.lockb. Lockfile commituj a na serveru instaluj pomocí bun install --frozen-lockfile.

Fungují přepínače oprávnění Dena na hostovaném tarifu?

Ano. Jsou to přepínače příkazu deno run, takže patří do spouštěcího příkazu nebo do úlohy v deno.json. Omezují tvůj proces; hostingový kontejner je samostatná vrstva izolace.