Open theburningmonk opened 9 months ago
Hey @theburningmonk , good to see you here.
I bet you want to run LLRT, that makes sense.
I had thoughts about this, should it also provide a bootstrap
file for you? we could also implement some custom runtimes like: llrt0.1.9-beta
and bun1.0.29
as an idea.
you forked the repo, Do you want to come up with some implementation?
Yup, trying to make using LLRT easier with the Serverless Framework!
I don't think it's necessary to provide the bootstrap file in the bundle, it's easy enough to bundle that as a layer, and I like being able to decouple the version of serverless-esbuild from the version of the LLRT bootstrap file.
I forked the repo last night to see what I need to do to make it support the custom runtimes, but I haven't looked closely enough to figure out the knock-on impacts of what node version the runtime is mapped to. So some feedback from you would be great.
If I add an option for AwsCustomRuntimes here: https://github.com/floydspace/serverless-esbuild/blob/master/src/helper.ts#L251
and map them to node20
, would that break someone's build if they are running node18? I didn't think it should, but I wasn't sure.
@theburningmonk 👋
I have been working on an rspack plugin for serverless (esBuild didn't meet some requirements we needed that the rspack api did).
The plugin has support for custom runtimes, and we are tracking LLRT closely.
https://github.com/kitchenshelf/serverless-rspack?tab=readme-ov-file#supported-runtimes
If you have nothing custom, it should be a drop in replacement for esbuild.
plugins:
- '@kitchenshelf/serverless-rspack'
custom:
rspack:
keepOutputDirectory: true
esm: true
externals:
- "^@aws-sdk\/.*$"
- "^@smithy\/.*$"
functions:
llrtFunction:
handler: 'src/functions/handler.main'
runtime: 'provided.al2023'
architecture: 'arm64'
layers:
- 'arn:aws:lambda:eu-bring-your-own-layer'
rspack: true
Let me know how you get on. LLRT is a big win for javascript apps so we too are wanting it to be easy with Serverless Framework 😄
EDIT: should note currently only tested against Serverless V3
For anyone who's looking for a quick solution, here is a workaround which works for me with serverless-esbuild
// provided-runtime-plugin.js
'use strict';
const fs = require('fs/promises');
const path = require('path');
class ProvidedRuntime {
constructor(serverless) {
this.serverless = serverless;
this.log = serverless.cli.log;
this.provider = this.serverless.getProvider('aws');
this.hooks = {
'after:package:initialize': this.beforePackage.bind(this),
'after:package:createDeploymentArtifacts': this.afterPackage.bind(this),
};
}
async beforePackage() {
this.log('\n# Copying provided runtime\n');
const buildDir = path.resolve(
this.serverless.config.servicePath,
'.esbuild',
'.build',
);
await fs.mkdir(buildDir, { recursive: true });
await fs.copyFile(
path.resolve(__dirname, 'llrt-lambda-x64-v0.3.0-beta-no-sdk'),
path.resolve(buildDir, 'bootstrap'),
);
}
async afterPackage() {
this.log('\n# Setting provided runtime\n');
this.serverless.configurationInput.provider.runtime = 'provided.al2023';
}
}
module.exports = ProvidedRuntime;
Is your feature request related to a problem? Please describe. When using Lambda custom runtimes, I'd like to use the plugin to bundle my js but the custom runtimes (
provided
|provided.al2
|provided.al2023
) are not supported.Describe the solution you'd like In the
helper.ts
module, add the Lambda custom runtimes to the list of supported runtimes.Describe alternatives you've considered Right now, the workaround I have is to:
Runtime
in the generated CloudFormation template AFTER serverless-esbuild has bundle and generated the artefactThis is obviously not ideal and is a barrier for to people to run out alternative runtimes like Bun and LLRT.
Additional context Looking at the
helper.ts
module, it needs to match the node version fromprovider.runtime
. We will need another way to tell serverless-esbuild which node version to use ifprovider.runtime
is one of the custom runtimes.