Forem: Tianhao Zhou

When npm install Fails with SELF_SIGNED_CERT_IN_CHAIN in Corporate Networks (Zscaler + Node 22 Deep Dive)

Tianhao Zhou — Sat, 14 Feb 2026 02:23:12 +0000

🚨 The Problem

Suddenly, npm install started failing across all projects with:

SELF_SIGNED_CERT_IN_CHAIN

It wasn’t repo-specific.
It wasn’t npm registry downtime.
It wasn’t a corrupt cache.

It happened everywhere.

Environment:

Node.js v22.x
npm v10.x
Corporate network (Zscaler SSL Inspection)
Windows + Git Bash

🔍 What Was Really Happening?

Our company uses Zscaler SSL Inspection, which performs TLS interception (MITM) for outbound HTTPS traffic.

So instead of the normal TLS chain:

registry.npmjs.org
    ↑
Public CA

The actual chain becomes:

registry.npmjs.org (re-signed)
    ↑
Zscaler Intermediate
    ↑
Internal Enterprise CA
    ↑
Enterprise Root CA

This is normal in enterprise environments.

❓ Why Did It Suddenly Break?

The key trigger was:

Node.js v22 tightened TLS validation behavior.

Older Node versions were more tolerant about incomplete chains.

Node 22:

Uses OpenSSL 3.x
Enforces stricter certificate validation
Does not auto-reconstruct incomplete intermediate chains

Providing only the enterprise root certificate is no longer sufficient.

🔬 How I Diagnosed It

First, I checked whether my local CA file contained a full chain:

grep -c "BEGIN CERTIFICATE" zscaler-root.cer

Result:

Only one certificate.

But when I inspected the live TLS connection:

openssl s_client -showcerts -connect registry.npmjs.org:443 \
  -servername registry.npmjs.org < /dev/null > /tmp/npm-chain.txt

Then:

grep -c "BEGIN CERTIFICATE" /tmp/npm-chain.txt

Result:

Five certificates were involved in the trust chain.

That was the smoking gun.

🛠 The Real Fix: Use the Full Certificate Chain

Step 1 – Split certificates

awk '/BEGIN CERTIFICATE/{i++} {print > ("/c/certs/npm-chain-" i ".pem")}' /tmp/npm-chain.txt

Step 2 – Combine into a full bundle

cat /c/certs/npm-chain-1.pem \
    /c/certs/npm-chain-2.pem \
    /c/certs/npm-chain-3.pem \
    /c/certs/npm-chain-4.pem \
    /c/certs/npm-chain-5.pem \
    > /c/certs/npm-full-chain.pem

Verify:

grep -c "BEGIN CERTIFICATE" /c/certs/npm-full-chain.pem

Step 3 – Configure npm and Node

npm config set cafile "C:\\certs\\npm-full-chain.pem"
export NODE_EXTRA_CA_CERTS=/c/certs/npm-full-chain.pem
npm cache clean --force

Then:

npm install

Success.

🧠 Why This Works

Node validates certificate chains strictly.

When behind corporate SSL inspection:

The leaf certificate is re-issued by Zscaler.
Multiple internal CA layers are involved.
Node must see the entire chain to validate trust.

If any intermediate is missing:

SELF_SIGNED_CERT_IN_CHAIN

Providing only the root CA is not enough in multi-level PKI environments.

💡 Why Browsers Worked

Browsers use the Windows certificate store.

Node does not (by default).

So:

Windows trusts enterprise root CA
Browser succeeds
Node fails

Different trust stores = different behavior.

🏢 Lessons for Enterprise Environments

If you're behind:

Zscaler
Blue Coat
Palo Alto SSL Inspection
Any corporate TLS interception

And using:

Node 20+
Node 22+
npm 10+

You may need to provide a full certificate bundle, not just a root certificate.

🔥 Key Takeaway

The error wasn't really about npm.

It was about:

Enterprise TLS inspection + multi-level internal PKI + stricter Node.js TLS validation.

Once you understand the trust chain, the fix becomes straightforward.

🚀 Final Thought

If you see:

SELF_SIGNED_CERT_IN_CHAIN

In a corporate environment, don’t disable SSL verification.

Instead:

Inspect the live TLS chain
Extract all certificates
Provide a complete CA bundle to Node

Security preserved. Problem solved.

If you found this helpful, let me know.
Enterprise TLS debugging is painful — but very educational.

Revisiting My esbuild Configuration: Lessons Learned from Snowflake and Prisma

Tianhao Zhou — Sun, 01 Feb 2026 10:22:56 +0000

In my previous post about using esbuild with Serverless, I shared a configuration that worked well at the time. However, after introducing a new dependency (snowflake-sdk), I had to revisit that setup — and along the way, I discovered that some of my earlier assumptions were incomplete or even wrong.

This post is a correction and clarification of that earlier article, based on what I learned during a much deeper debugging session.

The Trigger: Introducing snowflake-sdk

Recently, I needed to introduce a new dependency: snowflake-sdk.

Because snowflake-sdk includes native .node binaries, I followed the common advice and added it to the external field in my esbuild configuration:

external:
  - snowflake-sdk

The intention was simple:

Let esbuild skip bundling Snowflake, and load it at runtime instead.

Unfortunately, this time the build failed.

During compilation, esbuild encountered .node files and threw an error. This was my first signal that something fundamental had changed compared to my previous setup.

A Temporary Fix That Created a Bigger Problem

To unblock myself, I tried something that appeared to work:

I moved my esbuild configuration from custom.esbuild
Back to top-level esbuild

Surprisingly, the build passed.

However, this introduced a much more serious issue.

My previously working package.patterns configuration — which carefully excluded unnecessary Prisma files — stopped working entirely.

As a result:

A large number of unnecessary @prisma/client runtime files were bundled
The final Lambda artifact grew far beyond AWS Lambda’s size limit
I was stuck in a dilemma:
- Keep Snowflake working but exceed Lambda limits
- Control bundle size but break Snowflake

Clearly, I didn’t fully understand what was happening yet.

The Key Question: Why Does esbuild Behave Differently at Top Level?

At this point, the real question became:

Why does package.patterns work when esbuild is defined at the top level, but not when it lives under custom.esbuild?

After a lot of trial, error, and reading through build outputs, I realized the answer was not about package.patterns at all.

The real issue was external.

The Real Root Cause: external Changes the Packaging Model

Here is the critical insight:

When a dependency (for example @prisma/client) is listed in external
Serverless assumes it must be available at runtime
To guarantee this, it stops respecting package.patterns exclusions for that dependency
Instead, it ensures the dependency (and its transitive files) are included in the final artifact

In other words:

external implicitly overrides your intention to exclude files.

This explains everything.

Why My Previous Setup “Worked by Accident”

In my earlier build:

esbuild was configured at the top level
@prisma/client was listed in external

What I didn’t realize at the time was that:

The top-level esbuild path caused Serverless to use a different internal build flow
In that flow, external did not behave the same way
As a side effect, Prisma files were not force-included, and my bundle stayed small

So my previous success was not due to a correct understanding — it was an accidental alignment of behaviors.

The Correct Fix: Remove Prisma from external

Once I understood this, the correct solution became clear.

I tried one final experiment:

Keep esbuild under custom.esbuild
Remove @prisma/client from the external list
Let esbuild bundle Prisma normally
Keep package.patterns in place

To my surprise — and relief — it worked.

The build succeeded
Snowflake was handled separately
Prisma files were properly tree-shaken
The final bundle size stayed under 50 MB
No Lambda size limits were violated

This time, it worked for the right reasons.

Final Takeaways

Here are the key lessons I took away from this experience:

external is not just a bundling hint
It fundamentally changes how Serverless treats dependencies during packaging.
package.patterns cannot override runtime guarantees
If a dependency is marked as external, Serverless will ensure it exists — even if that means ignoring exclusions.
Top-level esbuild vs custom.esbuild can change behavior
Not because one is “better”, but because they trigger different internal build paths.
A working build does not always mean a correct build
My earlier configuration worked by coincidence, not by design.

Conclusion

This experience reminded me that build systems often fail silently — until they don’t. What looked like a simple Snowflake integration turned into a deep dive into how esbuild, Serverless, and packaging rules interact.

Hopefully, this correction helps others avoid the same confusion — and encourages a bit of healthy skepticism when a configuration “just works” without a clear explanation.

If you’re using esbuild with Serverless, especially with Prisma or native dependencies, understanding how external truly behaves is essential.

What a Failed Concert Ticket Purchase Taught Me as a Full-Stack Developer

Tianhao Zhou — Mon, 26 Jan 2026 09:07:38 +0000

Last weekend, I tried to buy tickets for a highly anticipated concert.
I didn’t get the ticket.

But as a full-stack developer, I walked away with something far more valuable:
a real-world lesson in how large-scale, high-concurrency systems actually fail.

This wasn’t a simple “sold out in 30 seconds” scenario. The ticketing platform eventually paused sales entirely, citing backend overload and system instability. What I experienced in the browser—loading states, retries, timeouts, and silent failures—was a live demonstration of distributed systems under extreme pressure.

Here’s what I learned.

Frontend “Loading” States Are Really Backend State Machines

From the user’s perspective, the page was just “loading”.

From the Network tab, it was clear that the frontend was reflecting a backend state machine:

verification requests

re-verification phases

long-polling

silent timeouts

eventual gateway failures

What looked like a spinner was actually the UI’s only way to represent:

“Your session may or may not still be eligible.”

Takeaway:

As frontend or full-stack developers, we’re not building buttons—we’re visualizing backend state transitions. If the state model is unclear, the UX will be confusing no matter how pretty the UI is.

Automatic Polling Is Normal at Scale (Even If It Feels Broken)

The page didn’t reload, but requests kept happening in the background.

This is typical for:

queue systems

long-polling

heartbeat-based eligibility checks

When systems are under extreme load, pushing state changes to clients is expensive, so the burden shifts to the client to keep asking.

Takeaway:

“Nothing is happening” often means “the system is busy deciding.”
Not all progress is visible.

A CORS Error Is Sometimes a Business Decision, Not a Config Bug

At one point, a critical verification request started returning a CORS error.

At first glance, this looks like a misconfiguration.
In reality, it often means:

the upstream service timed out or dropped the request

the edge layer returned a response without CORS headers

the browser blocked access to the response

In other words:

the system no longer considers your session worth responding to.

Takeaway:

Not every CORS error is a frontend mistake. In distributed systems, it can be the visible symptom of a backend refusal.

504 Gateway Timeout Is Sometimes a Polite “No”

A 504 error doesn’t always mean the server is slow.

In queue-based, fairness-critical systems, it can mean:

the system re-evaluated active sessions

your session didn’t make the cut

the backend stopped responding intentionally

the gateway timed out waiting

This is a soft failure, not a crash.

Takeaway:

Some HTTP errors are business outcomes disguised as infrastructure failures.

Queues Are Rarely FIFO in the Real World

We like to think queues are first-come, first-served.

In practice, eligibility is constantly re-evaluated based on:

session stability

retry behavior

network latency

concurrency from the same account or IP

risk or fairness heuristics

The queue is not a line—it’s a dynamic eligibility pool.

Takeaway:

If fairness matters, strict FIFO often doesn’t scale.

Systems Sometimes Prefer Downtime Over Unfair Success

Eventually, the ticketing platform halted sales completely.

This decision said a lot:

partial success was happening

many users were stuck mid-transaction

continuing would create unfair outcomes

trust would be damaged

So they chose consistency and integrity over availability.

Takeaway:

In high-stakes systems, fairness can be more important than uptime.

The Worst Failures Are Silent Ones

What made the experience frustrating wasn’t the failure—it was the ambiguity.

No clear “you’re out” message

No explicit retry guidance

Just endless waiting or vague errors

From a UX perspective, this is painful.

Takeaway:

Silent failures erode trust more than explicit errors.
Clear state communication is part of system reliability.

Users Will Do More Than You Expect

People don’t just click buttons:

they open multiple tabs

switch networks

inspect requests

wait strategically

retry at specific moments

Your system isn’t just used—it’s interpreted.

Takeaway:
Design systems assuming users are curious, persistent, and adaptive.

Incident Communication Is Part of the System

After the failure, the company released a public statement explaining:

what happened

why sales were paused

that integrity mattered

that the issue would be resolved

This wasn’t just PR.
It was incident response and trust repair.

Takeaway:

A system doesn’t end at the API boundary. Communication is part of reliability.

This Was a Real Production Incident, Not a Thought Experiment

Many developers never experience a true traffic surge incident firsthand.

This one had:

money

fairness constraints

global traffic

human emotion

executive intervention

Watching a system bend—and break—under real pressure is an education you can’t get from tutorials.

Final takeaway:
I didn’t get a concert ticket.
But I gained a deeper understanding of distributed systems, failure modes, and user trust.

That’s a trade I’ll take.

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

Tianhao Zhou — Thu, 15 Jan 2026 10:23:38 +0000

Here is a short, clean, blog‑friendly version that reflects your actual discovery:

How I Shrunk My Serverless Bundle by Discovering One Unexpected esbuild Issue

Today I finally solved a packaging problem that had bothered me for weeks:

no matter how many package.patterns I added — excluding Prisma engines, WASM files, TypeScript runtime, sourcemaps, caches — my AWS Lambda bundle never changed.

It didn’t matter if I excluded a few files or excluded everything.

The ZIP size stayed exactly the same.

Surprisingly, the fix had nothing to do with tree‑shaking, Prisma engine types, or exclude patterns.

The real culprit was something much simpler.

Problem: `package.patterns` didn’t work at all

I kept seeing massive files in the final ZIP:

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

Even if I removed all patterns:

package:
  patterns: []

The ZIP was still identical.

That meant Serverless was completely ignoring my configuration.

Root Cause: esbuild never ran

After turning on verbose mode:

npx serverless package --verbose

I saw no esbuild activity in the logs.

That’s when I realized:

My esbuild configuration was written under the wrong key.

I had something like:

custom:
  something:
    esbuild:
      bundle: true

But the serverless-esbuild plugin only reads config in one of two places:

Correct option A

custom:
  esbuild:
    bundle: true

Correct option B (newer style)

esbuild:
  bundle: true

Once I moved the config to the correct top‑level (sibling of custom):

esbuild:
  bundle: true
  minify: true
  target: node20

— everything started working immediately.

Serverless finally invoked esbuild, generated .cjs bundles, and only then did package.patterns begin affecting the ZIP.

Important: This had nothing to do with Prisma engine type

I originally thought the fix required switching Prisma to:

engineType = "client"

But that wasn’t necessary at all.

The only real fix was:

✔️ Move `esbuild:` to the correct level in `serverless.yml`.

Once esbuild finally ran:

The bundle size changed
Patterns were applied correctly
Unwanted files (WASM, engines, TypeScript) were finally excluded
The ZIP output became predictable and small

Why this happens

serverless-esbuild only executes when it finds config at the correct path.

If the plugin can’t see your config:

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

Fixing the config path fixes everything.

Takeaway

If your Serverless bundle:

is too big
ignores your exclude rules
keeps including Prisma engines, WASM, or TypeScript
or looks unchanged no matter what you do

Check this first:

Is your `esbuild:` block in the correct location?

If not, nothing else will behave as expected.

This one small change made the entire packaging pipeline work properly again.

How I finally understood when I can use useRef()

Tianhao Zhou — Sun, 05 Jun 2022 01:39:54 +0000

Currently I've got a ticket to build a react page with a map view.

Since it's a react app, I chose to use the Mapbox GL JS package. It allows you to load the map view as well as add custom markers.

In my case I have a list of companies to show in this app, and I also need to render the markers for each of the companies. At the same time I need to have filters on the result of companies. So the markers need to be re-rendered every time the results get filtered.

That requires me to remove the markers when I need to render new markers. So I will need an array to store the markers. I tried to declare a global variable first, but it wouldn't work, I guess it had something to do with the closure issue. Then I did a search using the key words such as 'how can I have properties in a function component'. Then I got the answer that I should can declare an array like:

const markers = useRef([])

And when I need to access it I will have to use

markers.current instead of markers

Replaced curl-request with http module.

Tianhao Zhou — Sat, 04 Dec 2021 01:15:20 +0000

I'm currently working on a celebrity face recognition app, leveraging the api provided by Clarifai team.

This api returns a list of candidates' name when you send a image url with celebrities face(s) to it.

To increase the performance, I decided to not only show the names of the candidates, but also attach a thumbnail of the celebrity, like this:

The solution came up to my mind is using wikipedia to get the profile page of that celebrity, which normally contains an image of the celebrity as well.

But how should I parse the page and retrieve the thumbnail url from it?

I tried to use the curl-request package first, which worked well locally. But when I tried to deploy it on Heroku, I got a whole bunch of errors. It turned out that one of the dependancy package of curl-request - node-gyp is not supported by node higher than 10.x, which is sebsequently not supported by npm higher than v6. When I use npm 6.x to build the project, I also get error from heroku.

To solve this conflict, I started to think about whether I really need to use curl-request. And the answer is No.

After googling, I found this solution - using http module to get the html code then parse it.

Sep 24 '20

A slightly modified version of @sidanmor 's code. The main point is, not every webpage is purely ASCII, user should be able to handle the decoding manually (even encode into base64)

function httpGet(url) {
  return new Promise((resolve, reject) => {
    const http = require('http')
      https = require('https');

    let client =

…

Open Full Answer

Up until now I've understood why we have to think carefully when we are adding a new package. Because when you add a new package, it means you are being dependant on it. Once it's deprecated, you might get trouble.

Forem: Tianhao Zhou

When npm install Fails with SELF_SIGNED_CERT_IN_CHAIN in Corporate Networks (Zscaler + Node 22 Deep Dive)

🚨 The Problem

🔍 What Was Really Happening?

❓ Why Did It Suddenly Break?

🔬 How I Diagnosed It

🛠 The Real Fix: Use the Full Certificate Chain

Step 1 – Split certificates

Step 2 – Combine into a full bundle

Step 3 – Configure npm and Node

🧠 Why This Works

💡 Why Browsers Worked

🏢 Lessons for Enterprise Environments

🔥 Key Takeaway

🚀 Final Thought

Revisiting My esbuild Configuration: Lessons Learned from Snowflake and Prisma

The Trigger: Introducing snowflake-sdk

A Temporary Fix That Created a Bigger Problem

The Key Question: Why Does esbuild Behave Differently at Top Level?

The Real Root Cause: external Changes the Packaging Model

Why My Previous Setup “Worked by Accident”

The Correct Fix: Remove Prisma from external

Final Takeaways

Conclusion

What a Failed Concert Ticket Purchase Taught Me as a Full-Stack Developer

Frontend “Loading” States Are Really Backend State Machines

Takeaway:

Automatic Polling Is Normal at Scale (Even If It Feels Broken)

Takeaway:

A CORS Error Is Sometimes a Business Decision, Not a Config Bug

Takeaway:

504 Gateway Timeout Is Sometimes a Polite “No”

Takeaway:

Queues Are Rarely FIFO in the Real World

Takeaway:

Systems Sometimes Prefer Downtime Over Unfair Success

Takeaway:

The Worst Failures Are Silent Ones

Takeaway:

Users Will Do More Than You Expect

Incident Communication Is Part of the System

Takeaway:

This Was a Real Production Incident, Not a Thought Experiment

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

How I Shrunk My Serverless Bundle by Discovering One Unexpected esbuild Issue

Problem: package.patterns didn’t work at all

Root Cause: esbuild never ran

Correct option A

Correct option B (newer style)

Important: This had nothing to do with Prisma engine type

✔️ Move esbuild: to the correct level in serverless.yml.

Why this happens

Takeaway

Is your esbuild: block in the correct location?

How I finally understood when I can use useRef()

Replaced curl-request with http module.

Problem: `package.patterns` didn’t work at all

✔️ Move `esbuild:` to the correct level in `serverless.yml`.

Is your `esbuild:` block in the correct location?