proposal-common-minimum-api VS serverless-esbuild

If you are considering building a modern JavaScript runtime I would suggest reading Minimum Common API.

Deno, CloudFlare Workerd, VM Labs WASM Worker Server, and others use some semblance of the ServiceWorker onfetch pattern as a server implementation. Why? Because onfetch of a ServiceWorker with Response() used to send a response to the client is ergonomic. Web API's being implemented by JavaScript runtimes that do not target the browser. In order to try to normalize implementation of Web API's for compatibility there is https://github.com/wintercg/proposal-common-minimum-api.

I guess you do not support Minimum Common API even though Node.js does?

Common I/O (stdin/stdout/stderr) module specification #47.

My goal for one part of this project was to use the same fetch() code in a Node.js and Deno Native Messaging host, respectively, in the spirit of Minimum Common API

The premise of this question is precisely why I filed Single HTTPS server for QuickJS, Bun, Deno, Node.js - without reliance on either to build #33. Closed as

Support Yarn PnP with externals bundling #327

We use serverless-esbuild to transpile our TypeScript code to JavaScript.

You should use appropriate tools to bundle your Lambda functions with a minimal size. For example, the Serverless Framework, with the serverless-esbuild plugin, automatically bundles your code and uploads it to AWS.

One of the most important aspects of serverless development is keeping an eye on your bundle sizes and to reduce cold start times on Lambda. Keeping this in mind, the template utilizes serverless-esbuild and serverless-analyze-bundle-plugin to provide function analysis out-of-the-box. I opted for serverless-esbuild over serverless-bundle for a few reasons:

Its faster and easier to setup that webpack and drastically reduces the size of the archive. For Serverless framework users there is https://github.com/floydspace/serverless-esbuild and if you use SAM CLI, you already get this for free since they now use esbuild in the build process

if you can, try using https://github.com/floydspace/serverless-esbuild - esbuild is stupid fast and it produces tiny artifacts. Its dead simple too compared to the webpacks/rollups/etc.