chore: Use Bun package manager & runner

[amitdahan]

Initially I wanted to use Bun for all the things:

• Package manager (bun install instead of npm i)
• Command runner (bun run or bunx instead of npm run or npx)
• Runtime (bun run --bun instead of node)
• Bundler (bun build instead of tsc)
• Single-executable (bun build --compile instead of pkg)
• Test runner (bun test instead of vitest)

In practice - it turned out to be a pretty big effort, so I'll try to split this into separate PRs, starting with:

• Package Manager
• Command runner

---

Mostly went smooth, except bun pkg.js which seemed to fail during Node binary fetch, so I still use node pkg.js in the release.yml workflow

---

CI gains:

• Install went down from around ~12s to ~0-1s
• Build takes ~1s less
• Setup Bun is ~2s faster than Setup Node (and not using cache so less teardown)

[luixo]

Awesome initiative! While digging inside CLI I noticed we use js extensions in imports. Is that the recommended way? It doesn't make much sense. Should we switch to extension-less import? Or to ts extension import?

[amitdahan]

@luixo

While digging inside CLI I noticed we use js extensions in imports. Is that the recommended way?

I believe it actually is. I couldn't find a good summary, but this StackOverflow answer might do it well enough.

It doesn't make much sense.

I agree.

Should we switch to extension-less import? Or to ts extension import?

This would require compilerOptions.allowImportingTsExtensions: true which also requires noEmit: true or declarationOnly: true, which implies not using tsc to build.

So I'd say when we stop using tsc to build our .js output - we could also change the imported extension to .ts, but also I feel this weirdness is unfortunately already pretty much "accepted" by the ecosystem (auto imports do the "right" thing, etc).

[amitdahan]

@luixo

As you still deep in the context of all the operations needed for CLI, I suggest adding CONTRIBUTING.md with explanation of whatever is needed to contribute / test / generate / build / release the CLI.

Agreed, will follow-up in a separate PR though.