https://bun.sh/ is amazing – let's explore moving the entire Playground to it. ## Bun "just works" Bun just does the right thing. I can point it to a file deep in a monorepo and it will resolve all the imports etc. without a single config f It seems like https://bun.sh/docs/bundler has na upper hand over Vite: * It's a single tool while Vite is rollup + esbuild and requires writing plugins for both build tools * It can handle browser libraries and server libraries without sweat (while Vite requires trickery) * It almost "just works" with zero config. No more paths issues or Vite plugins issues * The documentation seems nicer than Vite * It is fast – `bun packages/playground/cli/src/main.ts` just works, while in Vite we don't have a corresponding command so we need to build everything before running. * It's the same tool we'd use for the Playground server (#1056) * Maybe it would help us ditch `nx`? * ...there's more Here's how Bun performs at specific tasks. ### Development run This single command runs the CLI version of PHP.wasm: ```shell $ bun --watch ./packages/php-wasm/cli/src/main.ts Usage: php [options] [-f] <file> [--] [args...] php [options] -r <code> [--] [args...] ``` Here's what I _didn't_ do with Bun but had to do with Vite: * Write a config file * `cd` into the package directory first – I'm running this from the repo root! * Install a watcher or struggled to get it to work on my OS * Spend a week looking for the right set of plugins to get this setup to work * Run into module resolution issues around CJS, ESM, monorepo setup etc. * Run into any TypeScript issues ### Bundling I ran this command and Bun just bundled the `@php-wasm/cli` package: ```shell bun build ./packages/php-wasm/cli/src/main.ts --outdir tmp --target=node ``` Here's what I _didn't_ do with Bun but had to do with Vite: * **Wait for all the dependent `nx` builds – `bun build` took only 22ms!** * Write a build config that's separate from the dev config * Worry about ESM vs CJS of my code or the installed dependencies * Give up and write a separate esbuild setup because Vite couldn't do something I needed for Node.js ### Testing I ran this command and Bun just ran the tests: ```shell bun test ./packages/php-wasm/node/src/test/php-vars.spec.ts 1 ↵ bun test v1.1.3 (2615dc74) packages/php-wasm/node/src/test/php-vars.spec.ts: ✓ phpVar > Encodes Hello, World [17.39ms] ✓ phpVar > Encodes This is `Playground's` "test suite" [11.34ms] ✓ phpVar > Encodes This is \\`Playground's\` \"test suite\"\ [11.06ms] ✓ phpVar > Encodes $variables \$variables $$variables [11.12ms] ✓ phpVar > Encodes [10.75ms] ✓ phpVar > Encodes こんにちは [12.09ms] ✓ phpVar > Encodes %s [9.96ms] ``` Here's what I _didn't_ do with Bun but had to do with Vite: * Install a separate testing tool * Write a test config that's separate from the build or dev config * Worry about ESM vs CJS of my code or the installed dependencies ## New features ### Single-file executable Bun can build a TypeScript project into a single executable. We could use it to distribute a Playground CLI tool without worrying about Node versions, node_modules etc. ## Related Resources * https://github.com/WordPress/wordpress-playground/pull/1289 * https://github.com/WordPress/wordpress-playground/issues/1056 ## Concerns * Building, testing, and developing with Bun would mean we're not running Playground code on Node.js on a daily basis. Instead, Node would become a build target, an afterthought. How can we ensure the won't start breaking on Node? ## Notes * Bun can produce Node.js-compatible code. Node is a valid build target. * Bun can only produce ESM. We could either use rollup to also ship CJS version of our modules, or drop CJS support. Let's use #1056 as an excuse to explore switching to Bun for bundling packages