feat(build): Add AWS Lambda support

[Mushus]

This pull request adds support for deploying to AWS Lambda in @hono/vite-build . This allows Hono applications to be easily run in an AWS Lambda environment.

• Added an adapter for AWS Lambda ( @hono/vite-build/aws-lambda ).

You can verify that an application built using create-hono-app is working at the following URL: Examples x-basic template running on AWS Lambda Function URL

---

~~By the way, in the public/.assetsignore file of the x-basic template, .vite/ is listed. However, the output dist/index.js includes Oe.use("/.assetsignore",gt({root:"./"}));Oe.use("/favicon.ico",gt({root:"./"}));Oe.use("/.vite/*",gt({root:"./"}));Oe.use("/static/*",gt({root:"./"})); . This seems to be the build result of serveStatic. Is it okay that .vite/ is included here and not ignored in the code?~~ I researched .assetsignore and learned it's a Cloudflare-specific configuration file. Please disregard this question.

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 4218f7f6995539508e636a0abcea9fb30d6f31a6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[yusukebe]

Hi @Mushus

Can you add a test in packages/build/test/adapter.test.ts? And can you run yarn changeset on top of the project and push the generated file? This will be a feat change.

[Mushus]

Hi @yusukebe,

Thank you for your response.

After reviewing my implementation, I realized there are two key issues:

1. It doesn't support multiple AWS Lambda deployment patterns, such as:

• JS Lambda + API Gateway
• JS Lambda + Function URL (with assets bundled)
• CloudFront + JS Lambda + S3 (assets)
• CloudFront + Lambda@Edge (with bundled assets)
• CloudFront + Lambda@Edge + S3 (assets)
• Lambda using Docker runtime

2. Lack of package.json support inside the Lambda runtime. Since Node.js runs inside the Lambda environment, behavior changes depending on package.json. In my code, I had forcibly changed extensions to .mjs, but I later realized it would be better to include the original package.json to preserve expected behavior.

Given these issues, I believe the implementation in #271 is clearly of higher quality. Please feel free to prioritize that PR instead.

That said, I also noticed that there are still some deployment scenarios not fully addressed even in #274, particularly regarding asset handling and environment-specific configurations.

Many of the concerns I encountered may still be relevant for ensuring broader compatibility and flexibility, so I’d be happy to collaborate on improving and expanding this area further. Based on these findings, I’d also like to make a revised proposal in the future—either as a new PR or by opening issues to discuss specific deployment patterns and improvements.

[yusukebe]

@Mushus

Thank you for considering. Then, let's move on to #271.