tsup VS deno-lambda

Now, we can run all this server reaching the port 4000. If you want to test, build it with tsup or any other way that you want, like ts-node.

If you're building hooks, providers & components you can go with only React + TypeScript, and use something ESBuild or tsup to build it.

I am using `tsup` to transpile my application - https://github.com/egoist/tsup

I spent way to much time over the last couple days trying to line up vite/rollup to bundle my component library with types, type maps and the correct formats. Until I ran across this blog post which introduced me to https://github.com/egoist/tsup and it all just worked in a single readable command. I figured I'd share with you beautiful people so you could get your code bundled faster and carry on with the fun part of programming.

As we iterate on the definition, we are going to want a better developer experience for rebuilding the package on changes. Typically, for a “library” or “utility” style package, I’d reach for either unbuild’s stub concept or use esbuild/tsup/rollup to implement a more traditional watch/rebuild, but in this case, I’m watching a proto file that lives outsides of the source, which breaks assumptions of those tools.

My most recent project uses tsup to package a CJS and a ESM version separately, and I just publish both. It's too early to go full ESM, but I also don't want to stay on CJS, granted that we've been slowly moving away from it. To me as a dev it makes no difference, but if you want to use one or the other as a library consumer, you have a choice in my package

If you want to stay in that ecosystem, try tsup. But you should still try to wire up a canonical tsc-based project first to understand the fundamentals.

Have a look at tsup (https://tsup.egoist.dev) and microbundle (https://www.npmjs.com/package/microbundle)...

I actually recommend using tsup to build instead of tsc. It can bundle if you want, makes it easier to output multiple formats if you want, etc. It's also dead simple and lightning fast (like, MUCH faster than tasc). It's zero config so the build script is as simple as this.

Using Deno with AWS Lambda functions requires a custom runtime. You can build your own runtime or use one that already exists. If you’re concerned about security, I suggest maintaining a copy of an existing runtime and carefully inspecting updates or creating your own runtime. For this proof of concept, I deployed the Serverless Application Repository (SAR) app for Deno into my AWS account. I used the included Lambda layer and the provided.al2 Lambda runtime to create my Deno Lambda function. I created a file called index.ts with some basic JavaScript code that makes requests to two different websites and returns the HTTP status code of the response or a caught error. I then updated the function’s configuration to reference the exported handler function.

I'm doing a simple PoC / testing with Deno using https://github.com/hayd/deno-lambda and specifically the CDK instructions.

As I had mentioned, it requires using a Lambda Layer. See: https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e...

Using your own image (i.e. without using the base AWS image with the layer) you'd get even worse cold start times.

Decorators and TypeScript aren't supported out of the box in Lambda (without using deno) so we'll also need a transpilation step if we go this route. Fortunately this is a mostly solved problem for AWS CDK, AWS SAM and Serverless Framework users. If you want or need to roll your own, esbuild is a great place to start and seems to be the bundler of choice for this purpose.

In addition to the stuff posted here, there's the deno-lambda project for deploying to AWS Lambda

Cloud hosting support. Deno runs fine in a container, but lambda/cloud function support is difficult on most providers. deno-lambda exists but it only applies to AWS and can't be used with all CICD tools. Deno Deploy also exists but it's pretty new.