Auto-updated SLS binary bundle causes esbuild host/binary version mismatch

[JohnO-Ninetyio]

Issue description

When Serverless Framework v4 auto-updates to a release that bundles a different esbuild version than what's installed in the project's node_modules, the serverless-esbuild plugin fails with:

Cannot start service: Host version "0.27.3" does not match binary version "0.27.4"

Steps to reproduce:

1. Have a project using serverless-esbuild@1.57.0 which resolves to esbuild@0.27.3 in the lockfile
2. Run serverless offline (or any serverless command)
3. SLS v4 launcher auto-downloads the latest release (4.36.0) to ~/.serverless/releases/4.36.0/
4. SLS 4.36.0 bundles esbuild 0.27.4 native binary at
   ~/.serverless/releases/4.36.0/package/dist/node_modules/@esbuild/darwin-arm64/bin/esbuild
5. The serverless-esbuild plugin loads the JS API from the project's node_modules/esbuild (0.27.3) but the native binary resolves from the SLS bundle (0.27.4)
6. esbuild's strict version check fails

Expected behavior:

The SLS framework should not interfere with esbuild resolution when a plugin like serverless-esbuild manages its own esbuild dependency. The JS API and native binary should always resolve from the same location.

Actual behavior:

The JS wrapper and native binary resolve from different locations (project node_modules vs ~/.serverless/releases/), causing a version mismatch crash.

Workaround:

Add esbuild as a direct devDependency pinned to match the version bundled by the current SLS release:

npm install -D esbuild@0.27.4

This is fragile — the next SLS auto-update could bundle a different esbuild version and break things again.

Environment:

• Serverless Framework: 4.36.0 (auto-downloaded)
• serverless-esbuild: 1.57.0
• esbuild (project): 0.27.3
• esbuild (SLS bundle): 0.27.4
• Node.js: v22.22.0
• OS: macOS (darwin-arm64)

Context

No response

[czubocha]

Hey, thanks for reporting, we're looking into this.

[czubocha]

Hi @JohnO-Ninetyio - we’ve released a fix to the canary channel. Could you try the canary build and confirm whether the version mismatch error is gone?

To test it, set frameworkVersion to canary in your serverless config, then re-run the command that was triggering the error and let us know if the issue still occurs.

[czubocha]

Closing this since the fix has been shipped in v4.36.1.
Thanks again for reporting this and for providing a minimal repro!

[JohnO-Ninetyio]

Thank you @czubocha . I didn't have time yesterday to test the canary version. I'll look at the newest in 4.36.1