Package individually doesn't optimise package size

[PatrykMilewski]

Hello!
This plugin works great, thank you for sharing it!

I wanted to test, if it works for our use case and I've found some problems.

We are using Yarn as package manager with workspaces enabled. In the stack that I'm testing, we are having 4 lambda functions. When I was using Webpack, each lambda had different package size, where the smallest was 1.5 MB and the biggest was 3 MB.

However when I was experimenting with this plugin, it looks like, package individually option doesn't work. The package size is 6 MB for each lambda, which equals the size of package, that is created when package individually is disabled.

I was looking a little bit into the source code and it looks like, package individually option is handled by this plugin. Is this expected behaviour of esbuild? This is the config that I'm using:

custom:
  esbuild:
    packager: yarn
    bundle: true
    minify: true
    sourcemap: true
    keepNames: true

Versions:
"serverless-esbuild": "1.5.1"
"serverless": "2.3.0"
Node.js v12.19.1

[floydspace]

Hey @PatrykMilewski, thank you for using the plugin.
Indeed, I was able to reproduce. It's handled, but halfway. so it does not work properly now.
Will work on the fix as soon as I have time.

[PatrykMilewski]

@floydspace Thanks! Could you share some more details? Maybe I could fix it myself and create a PR?

[floydspace]

@PatrykMilewski the issue is that serverless by default packs everything that is in the this.serverless.config.servicePath folder, I replace this folder to .build one as all compiled artifacts are stored there during the compilation. But seems like we have to prepare artifacts for each lambda manually, so compile, zip it, and provide the archive as lambda artifact. the implementation by serverless-webpack could work, see: packageModules.js#L73

[dashmug]

Thank you for this package @floydspace. I am experiencing the same problem with v1.6.0.

[dashmug]

My workaround is to use the include.

functions:
  MyAPI:
    handler: src/core/my/handler.api
    package:
      include:
        - '!**'
        - 'src/core/my/**'
  TheirAPI:
    handler: src/core/their/handler.api
    package:
      include:
        - '!**'
        - 'src/core/their/**'

I don't have to do this with serverless-webpack.

[PatrykMilewski]

@dashmug Should work, but it's kinda annoying and might cause problems, like you use some common files and then you forgot to include them.

Using serverless-webpack solves the problem? But then isn't it slowing down the whole build? It ruins all of the benefits of quick build of ESBuild, isn't it?

[dashmug]

@PatrykMilewski I'm only reporting my current workaround in the hopes that it can help someone. It is indeed annoying to have to exclude/include them explicitly. I didn't need to do that with my other project using serverless-webpack and I get optimised packages per function.

I'm hoping the same functionality can make its way here in serverless-esbuild as well.

[olup]

Hoping for this feature as well, any updates on it ?

[floydspace]

Sorry guys, don't have time to focus on this issue.
If you want to use serverless-webpack as workaround I would suggest you use it in pair with esbuild-loader, so you would have the same fast build benefit

[yeukfei02]

@floydspace

I think this issue is something related to my issue:

#86

[olup]

@dashmug and @PatrykMilewski I have added a PR to optimize individual packaging: #87
I'd love to have your input on this ; if this is working with your repo, use cases, etc... Could you give it a try ?

[PatrykMilewski]

@dashmug and @PatrykMilewski I have added a PR to optimize individual packaging: #87
I'd love to have your input on this ; if this is working with your repo, use cases, etc... Could you give it a try ?

Sure! I will give it a try today or tomorrow, thank you!

[floydspace]

🎉 This issue has been resolved in version 1.8.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[PatrykMilewski]

I just tested it and it works great! Thank you @olup for fixing this issue!