Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to serverless package when no lambdas exist #503

Open
trend-adam-kinnell opened this issue Oct 15, 2023 · 4 comments · May be fixed by #545
Open

Unable to serverless package when no lambdas exist #503

trend-adam-kinnell opened this issue Oct 15, 2023 · 4 comments · May be fixed by #545
Labels
bug Something isn't working

Comments

@trend-adam-kinnell
Copy link

Describe the bug
When attempting to create a serverless package without any lambdas (and therefore code for esbuild to compile), the package step fails with an error Error: ENOENT: no such file or directory, lstat 'PATH_TO_REPO/.esbuild/.serverless'

It seems to be looking for the .serverless folder in the wrong place (within the .esbuild folder).

To Reproduce

  1. Create a new empty repo and install serverless, esbuild, and serverless-esbuild.
  2. Use the following minimal serverless.yml file that doesn't define any lambdas.
service: test
frameworkVersion: ^3

plugins:
  - serverless-esbuild

provider:
  name: aws
  runtime: nodejs18.x
  1. Run serverless package
  2. See error message Error: ENOENT: no such file or directory, lstat 'PATH_TO_REPO/.esbuild/.serverless'

Expected behavior
If there are no lambdas to package then serverless-esbuild does no work and the package step succeeds.

Screenshots or Logs
image

Versions (please complete the following information):

  • OS: Mac OSX Ventura 13.4.1 (22F82)
  • Versions:
    "esbuild": "0.19.4",
    "serverless": "^3.35.2",
    "serverless-esbuild": "1.48.5"

Additional context
This issue was introduced in [email protected] as it's the first version that shows this behaviour.

We try to install a base set of plugins across multiple repos - even those which are purely infrastructure/CloudFormation with no code. While esbuild and this plugin is not required in this repo and does not provide any benefit, we would still expect it to not cause any issues.

@trend-adam-kinnell trend-adam-kinnell added the bug Something isn't working label Oct 15, 2023
@trend-adam-kinnell
Copy link
Author

This also occurs if a repo does define lambdas, but they all have enabled: false set during a given deployment.

@bboure
Copy link

bboure commented Nov 9, 2023

I am experiencing the same issue.
This is probably an edge case as you would probably not need esbuild if you don't have any function in the first place, and most projects will have Lambdas anyway.

My use case is that I am working on a workshop and I want to start from an empty project (with no Lambda), but with some initial setup already done (like all the necessary plugins installed) as these steps are irrelevant to what I want to show.

@mvargas33
Copy link

mvargas33 commented Jan 16, 2024

This also happens to me when I try to run sls deploy, but with existing lambdas (many of them). If I run with [email protected] it fails with the same error as described above. If I run with 1.46.0 the error disappears and I can deploy successfully with nodejs18.x.

I had to adjust esbuild version to work with 1.46.0 or ˆ1.47.0 as well.

This is preventing my team from upgrading our lambdas to nodejs20.x. So it's an important issue.

One workaround we've found is to create the empty folder .esbuild/.serverless/ before running sls deploy and it works well with serverless-esbuild@ˆ1.50.0 and esbuild@ˆ0.19.0 (latest versions as of now).

But it's not an ideal solution.

@Kit-p Kit-p linked a pull request Jul 11, 2024 that will close this issue
@Kit-p
Copy link

Kit-p commented Jul 11, 2024

I believe this bug was introduced by #484, specifically this line in src/index.ts.

if (this.functionEntries?.length > 0) { // <-- this
  await this.bundle();
  await this.packExternalModules();
  await this.copyExtras();
  await this.pack();
}

By removing this if condition (i.e. reverting to before the PR), the error is gone and successfully packaged.

I have created a PR #545 with this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants