dnt VS undici

We are going to use dnt - Deno to Node Transform tool to build the npm package.

As already mentioned dnt might help you if you are willing to have deno as your primary development environment. I work in a project like this and the deno tooling is great. I don't even need a package.json since dnt will generate it for me.

Build it in Deno and then use dnt to create an npm package. That way you support both JS runtimes: https://github.com/denoland/dnt

Specifically, make my codebase be for Deno, use Deno built-in formatter, linter and testing, and use dnt (Deno to Node Transform) to generate an npm package containing ESM code and to test generated code. For testing in the browser, deploy the test content linked to the generated ESM code to Github Pages and use playwright/test. For Cloudflare Workers, use wrangler to set up a worker locally for testing. A schematic diagram is shown below.

I ended up building the library with Deno and compiling to Node.js CJS and ESM using https://github.com/denoland/dnt

Yes, TS code is compiled to run in browsers. You can compile and bundle using `deno bundle` if your project is developed in Deno. Since I'm using Deno for library development, I use the `dnt`[1] tool to compile them into ESM modules later consumed by esbuild in my Node-based projects/toolchains.

[1] https://github.com/denoland/dnt

Maybe this could help? https://github.com/denoland/dnt

Yeah: interestingly, they had a test for the biggest category of frame, but not for the two other categories: https://github.com/nodejs/undici/blob/main/test/websocket/se...

The test I contributed is very specific to the frame fix I made, but I should probably go back and contribute more tests in send.js that test other lengths too.

The native fetch in Node.js 18 is based on undici.

Sadly, Undici's slow. Reference issue.

Did you try just using the http lib, or even axios/node-fetch? The fetch API in node is very new and looks like there have been concerns about its performance: https://github.com/nodejs/undici/issues/1203

A library that can be handy is Undici - a great HTTP/1.1 client, see here where they apparently added unix:// support: https://github.com/nodejs/undici/pull/226

Afterwards, create your new project and install our lone requirement [undici](https://github.com/nodejs/undici) to make HTTP requests in Node.js by running:

Test coverage currently sits at 89%, hopefully will be stable soon.

undici

We implemented fetch API operation with Node without the need for any library imports. The thing to note that under the hood that the fetch implementation is done based on another HTTP client, undici, which is actually a HTTP client written specifically for Node.js. It is an HTTP 1.1 only client.

> ...enough insights of how much better/faster Deno is

We moved our Deno project to Node because of lack of lower-level APIs on their Conn interfaces [0][1], but otherwise for our use-case (lots of tiny HTTPS connections) Deno absolutely blew Node out-of-the-water. Even at p50 (100tps) Deno (v1.18) was 10x faster than Node (v17.x) [2]

RAM wise, I found Deno (v1.18+) use 10M or so higher for the same code-base.

[0] https://github.com/denoland/deno/issues/13636

[1] https://github.com/denoland/deno/issues/9109

[2] https://github.com/nodejs/undici/issues/1203#issuecomment-10...