feat: add support for alternative JS runtimes like bun or Deno

[MegaMaddin]

What problem does this feature solve?

As a customer/user of the CLI, I'd like to use different JS runtimes other than node. There are currently two alternative JS runtimes on the rise:

• bun
• Deno

It would be nice to get end-to-end support for them.

How would you implement this feature?

I'm currently running the Checkly CLI under Deno 2 and it works. Although the end-to-end experience isn't en point yet, since the CLI is not aware of the runtime.

So for some stuff you need to fiddle around a bit to get it running:

• imports in Deno are using the full name incl. suffix my/file/name.ts which fails when transpiling this via TSC on the deploy stage
• Type resolution not always works and requires "manual" imports
• When transpiling code, the CLI falls back to TSC instead of the runtime

[tnolet]

@MegaMaddin this would require our backend runners to also support bun and Deno.

[MegaMaddin]

@MegaMaddin this would require our backend runners to also support bun and Deno.

Why is that? I'm currently using Deno for most of my CLI deployments and it's working fine/ok-ish. This ticket is more about, detection and support of the runtime and calling out to e.g. Deno or bun for transpilation instead of using ts-node/tsc.

[tnolet]

@MegaMaddin this would require our backend runners to also support bun and Deno.

Why is that? I'm currently using Deno for most of my CLI deployments and it's working fine/ok-ish. This ticket is more about, detection and support of the runtime and calling out to e.g. Deno or bun for transpilation instead of using ts-node/tsc.

Aha, now I understand. Just for working locally. I've not seen this request from users, also not sure how much we would need to change and test to assure compatibility for this.

[MegaMaddin]

Just for working locally

Exactly, I guess it's mainly about detection and calling out to the runtime for transpiling code (if possible).