How I Finally Fixed My Serverless + esbuild + Prisma Packaging Nightmare

Published: (January 15, 2026 at 05:23 AM EST)
2 min read
Source: Dev.to

Source: Dev.to

The issue

For weeks my AWS Lambda bundle size never changed, no matter how many package.patterns I added or removed. The ZIP always contained massive files such as:

@prisma/engines/**
query_engine_bg.*.wasm-base64.js
*.wasm
typescript/**
prisma/**

Even with an empty pattern list:

package:
  patterns: []

the ZIP size remained identical. It turned out that Serverless was completely ignoring my configuration.

Root cause: esbuild never ran

Running the packaging command in verbose mode showed no esbuild activity:

npx serverless package --verbose

The problem was that my esbuild configuration was placed under the wrong key:

custom:
  something:
    esbuild:
      bundle: true

The serverless‑esbuild plugin only reads the configuration from one of the following locations:

# Option A
custom:
  esbuild:
    bundle: true
# Option B (newer style)
esbuild:
  bundle: true

The fix

I moved the esbuild block to the correct top‑level location:

esbuild:
  bundle: true
  minify: true
  target: node20

After this change:

  • Serverless invoked esbuild and generated .cjs bundles.
  • package.patterns started affecting the ZIP as expected.
  • Unwanted files (WASM, Prisma engines, TypeScript) were excluded.
  • The bundle size became predictable and small.

Why this happens

serverless‑esbuild only executes when it finds its configuration at the proper path. If the plugin can’t see the config:

  1. esbuild never runs.
  2. Serverless zips the raw source and node_modules.
  3. All package.patterns appear “broken” because they’re applied to the wrong file structure.
  4. The ZIP never changes.

Fixing the config path resolves the entire packaging pipeline.

Takeaway

If your Serverless bundle:

  • Is too large,
  • Ignores your exclude rules,
  • Keeps including Prisma engines, WASM, or TypeScript,
  • Or appears unchanged no matter what you do,

First check that the esbuild: block is in the correct location (either under custom.esbuild or at the top level). A single misplaced line can cause the whole packaging process to fail.

Back to Blog

Related posts

Read more »

Rapg: TUI-based Secret Manager

We've all been there. You join a new project, and the first thing you hear is: > 'Check the pinned message in Slack for the .env file.' Or you have several .env...

Technology is an Enabler, not a Saviour

Why clarity of thinking matters more than the tools you use Technology is often treated as a magic switch—flip it on, and everything improves. New software, pl...