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 »

𝗗𝗲𝘀𝗶𝗴𝗻𝗲𝗱 𝗮 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻‑𝗥𝗲𝗮𝗱𝘆 𝗠𝘂𝗹𝘁𝗶‑𝗥𝗲𝗴𝗶𝗼𝗻 𝗔𝗪𝗦 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗘𝗞𝗦 | 𝗖𝗜/𝗖𝗗 | 𝗖𝗮𝗻𝗮𝗿𝘆 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁𝘀 | 𝗗𝗥 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿

!Architecture Diagramhttps://dev-to-uploads.s3.amazonaws.com/uploads/articles/p20jqk5gukphtqbsnftb.gif I designed a production‑grade multi‑region AWS architectu...