Local/Docker build crashes on startup when the blog fetch fails (ERR_TLS_CERT_ALTNAME_INVALID) — could the build degrade gracefully?

[pattang56892]

Hi, and thanks for maintaining this — the remote-friendly companies list is genuinely useful.

I cloned the repo and tried to build/run it locally using the Docker setup that ships with the project, and the build crashes immediately, before any site is generated. I wanted to flag it and suggest a small robustness improvement.

What I did

• Cloned the repo.
• Ran the bundled Docker setup: docker compose up --build (which runs npm start → bin/serve-site.js → bin/build-site.js).
• It also reproduces with a plain npm start.

What happened
The container exits with code 1 at the very start of the build. The relevant log:

bin/serve-site.js
Parsing content
Requesting URL "https://blog.remoteintech.company/"
Unhandled promise rejection: Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: blog.remoteintech.company is not in the cert's altnames: DNS:*.wordpress.com, DNS:wordpress.com
at Object.checkServerIdentity (node:tls:455:12)
...

Root cause as far as I can tell
Two things combine:

1. buildSite() in bin/build-site.js begins by fetching https://blog.remoteintech.company/ to scrape the WordPress.com theme (stylesheets/header/footer) that wraps the generated pages. That blog runs on a custom domain that is currently serving a *.wordpress.com
   certificate which doesn't cover blog.remoteintech.company, so Node rejects the TLS handshake. (Looks like a custom-domain SSL provisioning issue on the WordPress.com side.)
2. The global process.on('unhandledRejection', …) handler calls process.exit(1), so that one failed fetch takes down the entire build — with a large certificate dump and no actionable guidance.

So the build has a hard, un-cached dependency on a live external fetch, and any hiccup in that fetch is fatal.

Why I think it's worth improving
The real content of the site is the company-profiles/ data; the blog fetch only supplies decoration (theme CSS/header/footer). It feels fragile that a newcomer running the project through the very Docker setup the repo ships hits a hard crash because of an external
service's TLS state — and the error doesn't hint at what to do next.

Suggestions (rough priority order)

1. Degrade gracefully — wrap the blog fetch in a try/catch and fall back to a bundled/cached copy of the theme (or a minimal built-in stylesheet) so the build still completes with the company list intact.
2. Make the error actionable — on failure, print a clear message (what it was fetching, why it failed, that it's using a fallback) instead of a raw unhandled-rejection cert dump.
3. Cache the blog assets in the repo so the build doesn't depend on a live network call every time — faster, reproducible, and CI/offline-friendly.
4. Separately, the cert mismatch on blog.remoteintech.company itself probably needs reprovisioning on the hosting side.

How I worked around it locally (for reference only)
Setting NODE_TLS_REJECT_UNAUTHORIZED=0 for the build lets the fetch through and the site builds fine. I mention it only to confirm the root cause — I'm not suggesting you adopt it, since it disables certificate validation process-wide.

Happy to test or open a PR for the graceful-fallback piece if that'd help. Thanks again!

[dougaitken]

Good catch @pattang56892 - no idea why that is still in there, I'll get this fixed later.