Migrate from Deno to Bun

[yHSJ]

This PR migrates the entire codebase from deno to bun. I've organized the work in phases, working bottom-up in the dependency graph.

Progress

• Root workspace setup (package.json with Bun workspace globs)
• Convert packages/ (effectstream-sdk, node-sdk, chains, build-tools)
  • I have not yet migrated build-tools/tui, as @acedward has mentioned he may remove that entirely
• Convert tests (bun:test, run-tests.sh)
• Convert e2e/ (all 13 packages)
• Convert CI/CD (Dockerfile, patch.sh)
• Convert templates/
• Migrate publishing pipeline (all packages should be published on npm. This must be done by @acedward)
• Cleanup (delete deno.json/deno.lock, remove dead Deno guards, address any failing tests)

Important Decisions

Switching from deno to bun implies several decision points, mostly regarding dependencies (some are only on JSR, which is harder to use with node, and some have strict deno requirements).

• @Oak/oak
  I removed the @Oak/oak as it is only published on JSR. I decided to use Fastify instead, as it was already used in the codebase and easy to replace.
• deno task -f <pkg> <script>
  For all workspace-scoped tasks, I've replaced the deno task logic with bun run --filter <pkg> <script>. Recursive tasks (deno task -r) use bun run --filter '*'
• @sylc/dkill
  Replaced with fkill, since dkill was JSR only. fkill was the inspriation for dkill, so it was a simple change
• @std/log
  I made no decision about choosing a logger, since there are several options. Instead, I temporarily replaced the logger with console calls. We should replace this with a proper logging library.
• patch.sh
  patch.sh` was used to patch certain dependencies. I assume they were mostly workarounds for Deno, but I kept them just in case. If it's no longer needed, we should remove the script.
• build-tools/tui
  I left this untouched, as it almost entirely depends on Deno and likely will require a complete rewrite. @acedward also mentioned removing it completely.

[acedward]

@Yiakman I commented this out, but we didn't have the chance to talk about it.

[acedward]

@Oak/oak
I removed the @Oak/oak as it is only published on JSR. I decided to use Fastify instead, as it was already used in the codebase and easy to replace.

Perfect 👍

deno task -f <script>
For all workspace-scoped tasks, I've replaced the deno task logic with bun run --filter <script>. Recursive tasks (deno task -r) use bun run --filter '*'

I think there is no other way, if working with a bun workspace 💯

@sylc/dkill
Replaced with fkill, since dkill was JSR only. fkill was the inspriation for dkill, so it was a simple change

🥇

@std/log
I made no decision about choosing a logger, since there are several options. Instead, I temporarily replaced the logger with console calls. We should replace this with a proper logging library.

Yes 👍
We are routing though the stdout > TUI & stdout > otel collector ; but it was related on how the TUI worked. So this will need to be refactored, it's not critical in any way.

patch.sh
patch.sh` was used to patch certain dependencies. I assume they were mostly workarounds for Deno, but I kept them just in case. If it's no longer needed, we should remove the script.

🙏 Oh, i hate this script - just patches for deno issues

build-tools/tui
I left this untouched, as it almost entirely depends on Deno and likely will require a complete rewrite. @acedward also mentioned removing it completely.

👍 The main issue here is that running with --filter does not work the same as running a file directly. Ink does not start.