Deno brainstorming

[steida]

This is not a suggestion, this is a brainstorming slightly related to fp-ts and its ecosystem.
What if fp-ts would be written in Deno?

The first question is why. Deno has nice features (it's a complete and unified toolchain), we know, but the main reason why I am opening this discussion is that I struggle with a universal ESM library written both for browsers and Node. It's a pain to manage all different ts configs on all platforms. The main reason is that ESM for browsers and ESM for Node 16 are different.

https://stackoverflow.com/questions/71463698/why-we-need-nodenext-typescript-compiler-option-when-we-have-esnext

TLDR; It's not so easy. Node ESM is different. My lib is written with "module": "ESNext" but Node 16 ESM can't handle export * from for some reason (I have to export names explicitly). It probably means I have to write my universal lib with "module": "Node16", "moduleResolution": "Node16". but that seems to be wrong. Maybe I need some special tsconfig, or two...

The biggest Deno promise is unifying, I suppose. For npm and Node.js, there can be two build pipelines to their ESM formats via (denoland/dnt).

Again, I do not recommend that fp-ts be written in Deno first. I am just curious about what you think about it.

[mikearnaldi]

To me a system that aims at unifying and ends up requiring additional pipelines to emit standard js is a loss (if anything something actually aiming to unify could be the early stage 'bun' that is compatible with standards). That said with the HKT encoding that v3 will probably use it should make life easier for deno usage given that it no longer depends on module augmentation that if I remember correctly was the biggest blocker for deno usage

[steida]

You are correct. Btw, I am not proposing using a Deno because of Deno but because that could be a chance to unify the whole fp-ts ecosystem. Imagine what if writing a new fp-ts lib would be just writing one file with one test with zero configs. It looks like the ESM library will not always work everywhere out of the box as I would expect from the ESNext module in tsconfig. Also, no npm publishing is required for the Deno ecosystem, people can use master or branch from git directly.

I will try that approach to see how it works.

[steida]

So I tried to make something in Deno for the third time and failed again. The main problem is the lack of peer dependencies, which is OK on the server, but bad for frontend development where bundling several different versions of the same lib is just wrong. Also, deno lint is not extensible. And deno test is not as powerful as Jest. Etc. From my point of view, Bun is (or has a chance to be) what Deno was supposed to be. Maybe Node will fix itself with the better support of TypeScript and performance, and that's it.