feat: enable deno

[guy-borderless]

Closes #515

This is WIP branch that refactors the dev and init commands to centralize all JS runtime references and add deno support. This also adds a reference deno project using Deno's built in HTTP server.

✅ Checklist

• ✅ I have followed every step in the contributing guide
• ✅ The PR title follows the convention.
• ✅ I ran and tested the code works

---

Testing

[Describe the steps you took to test this change]

---

Changelog

[Short description of what has changed]

---

Screenshots

[Screenshots]

💯

[changeset-bot]

⚠️ No Changeset found

Latest commit: 007a015

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[guy-borderless]

@matt-aitken Hi matt, looks good so far?

[guy-borderless]

OK, tested what I can and everything works. It's not a big change, just all runtime-specific functions now go through a JsRuntime class, other than that code is unchanged.

The deno JsRuntime does not implement

  async checkForOutdatedPackages() {
    // not implemented currently
  }
  async getUserPackageManager() {
    return undefined;
  }
  async getFramework() {
    // not implemented currently
    return undefined;
  }

• getUserPackageManager: deno uses the ESM modules standard so no need for a package manager (we can return "ESM" in the future if it'll make sense).
• getFramework: can be implemented, but I think it's best to wait for deno 2.0 to do so as it would be much easier
• checkForOutdatedPackages: can also be implemented but I think best to wait for deno 2.0

docs:
deno is indeed just a runtime, and the express trigger-integration works on deno as expected. So I'm not sure that besided the reference project we should add "deno" or "deno built in Http Server" to the "frameworks" section of the docs, although if you think otherwise I'll be happy to do it. Maybe just add a FAQ question like "Can I use deno to build trigger.dev workflows".
what do you think?

[guy-borderless]

Regarding, docs, once we'll get this in I'll contribute a fresh integration. Any update on this?

[matt-aitken]

This is great @guy-borderless. Thanks a lot!

[matt-aitken]

Regarding, docs, once we'll get this in I'll contribute a fresh integration. Any update on this?

It would be great to add support for fresh.