and finally I was wondering : i think sst is building my lambda with esbuild. Is there a way to : bundle individually, declare externals ?

Yeah we definitely want to handle externals better. @Jay how should we do this? Should the

sst.Function

construct take an externals option?

that would be great. As I pointed out in one of your issues, i thing a global esbuild config could be passed on your Function construct. Maybe the build param could take either a bool or a config - that would map to esbuild config ? We do it in serverless-esbuild and add some logic around the declared externals.

Got it.. yeah we’ll probably be looking at the plugin code when we work on this 😄

Man, that is fast 😄 Have you been carefull to package the externals with the bundled function ? Do you control externals versions from node modules ? From the top yarn.lock (in case of a workspaced project) ?

Yeah, it packages the externals with the versions from node modules, and respecting the yarn.lock/package-lock.json. And uses the corresponding packager.

ok, but then what about yarn workspace ?

Yeah, I’ll probably either traverse up or add an option to take the lock file path down the road.

that sounds like the way to do

Yeah.. I’m curious to see how many ppl use yarn workspaces with SST

in serverless-esbuild we give that option, and also infer workspace use

Ah I see

Well, I think SST is used in conjunction with monorepo pattern often, or I think it will be

LOL yeah.. we are in the middle of migrating Seed to SST as well

do you use a monorepo ?

yeah with Serverless Framework, most ppl have multiple services, so a monorepo is a must

exactly

Yeah, it’s mostly @Jay and I on the dev side.

amazing, you seem to be coding quite fast