Findings No. 38
A dependency installed from a CDN URL is an outage surface you are not watching
node-xlsx pins xlsx to a cdn.sheetjs.com tarball. The CDN returned 403 to Vercel's build servers and failed a production deploy with no code change. We vendored it.
A dependency that installs from a URL instead of the npm registry makes every future build depend on that server being up and willing to answer you.
In Replicator, node-xlsx pins xlsx to a tarball on cdn.sheetjs.com, because SheetJS does not publish current versions to npm. One day the CDN started returning 403 to Vercel's build infrastructure specifically, and a production deploy failed with no code change on our side. Nothing in our repository had changed, and nothing in our monitoring would have predicted it.
The fix was to vendor the tarball into the repository (vendor/xlsx-0.20.2.tgz) and add a package.json overrides entry pointing at the local file, so installs no longer fetch it over the network.
The general rule: audit your lockfile for anything resolving through a CDN, a git URL or raw GitHub. Each one is an external outage surface for every build you will ever run, independent of your own code, and the safest fix is to vendor it.
Receipt: Replicator v3.193.2 (vendor/xlsx-0.20.2.tgz, the overrides entry in package.json; FINDINGS.md, "Vercel").