Deno support

[achinaou]

Are there any plans to support Deno?

[mikearnaldi]

Short: No.

Long: Deno bundles tsc with itself and, apart from it being a completely insane model, it prevents us from using compiler plugins that are needed for execution tracing & optimizations additionally the module pattern that Deno uses is non-standard.

Advice: Treat Deno like any other JS target and compile TS independently it will be faster to run and more reliable.

[achinaou]

Thank you for the answer, the explanation, and the advice!

[mikearnaldi]

Re-opening for posterity, following a discussion with a deno contributor https://twitter.com/MichaelArnaldi/status/1478344273007460354 the only solution to ever support deno will be to fork deno.

I personally have no bandwidth to do that but if anyone wants to try I'd be happy to help.

[schickling]

Looks like the upcoming version Effect will be usable with Deno? That's very exciting. Ideally there would be a little sample project for this :)

[mikearnaldi]

So Deno in theory can be used given we no longer rely on module augmentation for HKTs and all imports are global imports compliant with esm, that said HKTs aren't final and will be part of @tsplus/stdlib but I don't envision a reason to need again augmentation.

On the topic of effect with TS+ and tracing it is unfortunately not a possibility in the short term given that the Deno stack is pretty tightly coupled with the tsc they use and the compilation chain, it would require a fork and potentially a re-join after a while if a stable integration is developed

[steida]

@mikearnaldi Did you change your mind about the esm? I remember you told me it's a no-go if I understood it correctly.

[mikearnaldi]

@steida no pretty much the same opinion, we cannot publish a package with type: module because of compatibility with the ecosystem. The rule for identify a file as a module in a package is that either it must be in a package with type set to "module" or it has to be an ".mjs" extension and work has been done to publish one package with package exports and esm files named as file.mjs so that you can use it in a package as a module and it is compliant with node's esm spec

[steida]

@mikearnaldi What if this lib would be written in Deno and compiled/transpiled to Node/whatever? There are a few advantages.

[mikearnaldi]

@steida there are a few advantages and also many disadvantages, this library is written in TS+, the design of Deno doesn't allow for custom compilers to be used so it isn't a possibility (and even if it was the module structure of using https imports isn't something I like nor that I'll ever envision using). A potential path forward if anyone is interested enough may be to fork Deno, at least temporarily, and get support for TS+, if that happens it may make sense

[pmanole-volvocars]

@mikearnaldi, I think Deno 2.0 which is in RC phase, aims to have full Node.js compatibility? Could this be working now?

I quickly tried spinning up a new Deno project with the latest RC and added some lines:

import { Effect } from "npm:effect";

const program = Effect.log("Program works");

const programSucceed = Effect.tryPromise({
  try: async () => {
    return await Promise.resolve("Promise resolved");
  },
  catch(err) {
    return new Error("Promise rejected", { cause: err });
  },
});

const programReject = Effect.tryPromise({
  try: async () => {
    return await Promise.reject("Promise rejected");
  },
  catch: (err) => {
    return new Error("Promise rejected", { cause: err });
  },
});

const all = Effect.all([program, programSucceed, programReject]).pipe(
  Effect.catchAll((err) =>
    Effect.logError({
      where: "catchAll",
      message: err.message,
      cause: err.cause,
    }),
  ),
);

Effect.runPromise(all);

Output:

timestamp=2024-09-25T00:22:07.003Z level=INFO fiber=#0 message="Program works"
timestamp=2024-09-25T00:22:07.004Z level=ERROR fiber=#0 message="{
  \"where\": \"catchAll\",
  \"message\": \"Promise rejected\",
  \"cause\": \"Promise rejected\"
}"

[mikearnaldi]

@mikearnaldi, I think Deno 2.0 which is in RC phase, aims to have full Node.js compatibility? Could this be working now?

I quickly tried spinning up a new Deno project with the latest RC and added some lines:

import { Effect } from "npm:effect";

const program = Effect.log("Program works");

const programSucceed = Effect.tryPromise({
  try: async () => {
    return await Promise.resolve("Promise resolved");
  },
  catch(err) {
    return new Error("Promise rejected", { cause: err });
  },
});

const programReject = Effect.tryPromise({
  try: async () => {
    return await Promise.reject("Promise rejected");
  },
  catch: (err) => {
    return new Error("Promise rejected", { cause: err });
  },
});

const all = Effect.all([program, programSucceed, programReject]).pipe(
  Effect.catchAll((err) =>
    Effect.logError({
      where: "catchAll",
      message: err.message,
      cause: err.cause,
    }),
  ),
);

Effect.runPromise(all);

Output:

timestamp=2024-09-25T00:22:07.003Z level=INFO fiber=#0 message="Program works"
timestamp=2024-09-25T00:22:07.004Z level=ERROR fiber=#0 message="{
  \"where\": \"catchAll\",
  \"message\": \"Promise rejected\",
  \"cause\": \"Promise rejected\"
}"

With npm imports the library works fine indeed

[danielo515]

I came here because I was not able to find a platform implementation for deno. So the current status is that it is not officially supported, and that only works with npm: prefix? What should we use for http servers and other implementations? The node one?

[mikearnaldi]

I came here because I was not able to find a platform implementation for deno. So the current status is that it is not officially supported, and that only works with npm: prefix? What should we use for http servers and other implementations? The node one?

So first of all using the npm prefix doesn't mean it's not supported it just means you're using npm as a registry, Deno and JSR are different projects and publishing on JSR exposes a Pandora box in terms of potential duplication of packsges, keeping a single publish is the safest bet, hopefully JSR will implement npm compatibility in the sense that JSR packages can depend on NPM (at the moment the opposite is true).

The other thing is, Effect officially supports Deno too but this isn't the case for ecosystem modules like effect/platform, this isn't because we have a case against Deno but rather because we have a single monorepo and tooling where we can easily test standard runtimes such as node, bun, browser, edge, and unfortunately in the same setup Deno doesn't work, the day that Deno supports monorepo like we have will be the day we add Deno support to platform

[lishaduck]

Hopefully JSR will implement npm compatibility in the sense that JSR packages can depend on NPM (at the moment the opposite is true).

Did you mean to say that backward? JSR supports packages that depend on npm packages, npm just doesn't support JSR (natively, I think published packages should also be able to use the npm-registry compat layer that the jsr-npm cli uses, though forcing users to add a custom registry is certainly not ideal).
Therefore, it should be possible to create a jsr:@effect-ts/effect that just re-exports npm:effect, and a jsr:@effect-ts/platform-deno.¹ Essentially, it'd be like the "ESM-wrapper" solution for the CJS-ESM dual-package hazard.

The other thing is, Effect officially supports Deno too but this isn't the case for ecosystem modules like effect/platform, this isn't because we have a case against Deno but rather because we have a single monorepo and tooling where we can easily test standard runtimes such as node, bun, browser, edge, and unfortunately in the same setup Deno doesn't work, the day that Deno supports monorepo like we have will be the day we add Deno support to platform

Deno supports npm workspaces as of (denoland/deno#18546). Vitest compat is also getting active work (denoland/deno#23882); I just tried it and it works great, though coverage is broken on stable (it might fixed on canary right now, I haven't tried it). I'd guess coverage will probably get fixed by 2.1. Are there any other blockers?

I've started implementing it in jsr:@lishaduck/effect-platform-deno, and would love to upstream it.

Footnotes

1. A little sleuthing and it looks like Tim already owns @effect-ts, so I used that. If you'd prefer the @effect scope, it looks unused and per the name squatting policy you should be able to get it if you want ↩