Extra file (package.json) not included into final zips

[doteric]

Describe the bug
Extra files (package.json to be exact) are not included into the final zips.

Versions (please complete the following information):

• OS: Mac
• Serverless Framework Version: 3.18.2
• Plugin Version: 1.30.0

Additional context
So basically I wanted to use esbuild with ESM (AWS supports this for a while already). I set the type inside package.json to module and everything else needed for this move, worked fine, but the problem I stumbled upon is that serverless-esbuild simply does not include the package.json into the zip even if it's added to the package.patterns like so below.

custom:
  esbuild:
    bundle: true
    minify: false
    packager: 'yarn'
    target: 'node16'
    keepOutputDirectory: true

package:
  individually: true
  excludeDevDependencies: true
  patterns:
    - 'package.json'

It looks like the .esbuild contains the the package.json, but the zips themselves don't.

Of course I could just name my files .mjs instead, but that isn't an ideal solution for me.

[doteric]

Ok, I started to look through the code after reporting the issue and I think I found it.
https://github.com/floydspace/serverless-esbuild/blob/master/src/pack.ts#L38

const excludedFilesDefault = ['package-lock.json', 'pnpm-lock.yaml', 'yarn.lock', 'package.json'];

What's the reasoning behind this?
And it looks like the only way to disable this is to set the provider to google 🙄

@floydspace So I can make some PR, but question - do we want this default or can we just remove it? If somebody wants to exclude any of the 4 then he can simply add some pattern themselves. If you don't want to do such then it'll require creating some additional option probably.

[floydspace]

hi @doteric , to be honest, not sure what is the reason we exclude, maybe because anyway we deliver bundled code and package.json used to be just unnecessary development artifacts, but feel free to test it locally with patch-package for instance and let as know, if you'd like raise a PR, keep in mind that we do not use root package.json for packaging dependencies, we generate one here https://github.com/floydspace/serverless-esbuild/blob/master/src/pack-externals.ts#L293, maybe it makes sense store this file, not the root one, but we'd also have to copy some necessary module meta located in root package.json you mentioned, so your js files are treated correctly by nodejs.

[doteric]

Hey @floydspace, thanks for the reply.
This package.json seems to be generated only if there are external modules specified, right? Anyway it seems to be a bit mixed up. For now I'll hold with the PR as I don't have much time, but I assume the goal would be to use the base package.json and replace it with the necessary params (dependencies for example) generated by the package.json from the pack-externals.

[floydspace]

@doteric yes, you're absolutely right, only external modules, here is the thing, other dependencies are bundled and you don't need them in generated package.json. so your assumption is correct, but could be vice versa, some of the params from base package.json would be copied to generated one, because you probably do not need scripts for instance nad other dev specific meta.

[mpaleo]

@doteric Lambda relies on the package file or the file extension, so you could do something like this in your serverless.yml:

esbuild:
  format: esm
  outExtension:
    .js: .mjs

Ref: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html

[mpaleo]

BTW, getting the package.json deployed to Lambda is still really useful, because if you combine outExtension with external, it will fail because it doesn't find the original one.

esbuild:
  format: esm
  outExtension:
    .js: .mjs
  external:
    - typeorm

[doteric]

Thanks @mpaleo for the suggestion.
I haven't tested your suggestion, but I think some problems may occur.

Anyway regarding this case I've decided to not use serverless altogether as I'm not using much of it's features apart from the packaging (using terraform for the infra deployment) and decided to build my own simpler packager that does the job for me.

[github-actions]

🎉 This issue has been resolved in version 1.32.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀