Blog
npm Install Failures During an SDK Evaluation
Evaluators die on ERESOLVE, engine mismatches, and private registry 401s before your SDK loads. Those exits never hit your API. The CLI or a postinstall message has to name the next command.
2026-09-08 · 6 min read · AethelLayer
Install is the first product surface
If npm install fails, you do not have a user. Peer dependency conflicts and an engines field that rejects their Node version are the usual stops. Print the Node version you require next to the package version.
A postinstall script that assumes a global tool exists will fail in CI and on a fresh laptop. Make that tool optional or print the install command for it.
Private registries look like your bug
A 401 from their company registry, while installing your public package, is their .npmrc. The error still shows your package name. Document a one-line public-registry install so they can tell the two apart.
Do not ask them to paste npm-debug.log into email. It contains tokens. Ask for the error code and the Node version.
You only see this if you wrap the command
Your server never observes a failed install. Wrap the documented install in the probe if you ship a CLI, or tell the README's failing command to write a local record.
Group by the npm error code. ERESOLVE and EACCES are different docs.
Pin what you test
Test the quickstart on the oldest Node in your engines field and on current. A range you do not run is a range you will hear about from people who do not file tickets.
When a lockfile bump breaks the sample, say so in the release note with the error code.
Keep reading
Capture the failure before they leave
Capture the failure before they leave. Book early access or talk to sales, then install @aethellayer/sdk when you are onboarded.