Clinging to Life on an Obsolete Intel Mac

On 13 August 2026, Apple listed my old Intel MacBook as an obsolete product. According to the official description:

Products are considered obsolete when Apple stopped distributing them for sale more than 7 years ago.

…

Apple discontinues all hardware service for obsolete products, and service providers cannot order parts for obsolete products.

…

That means that, except for the battery, I cannot get any repairs from official support. I would only be able to try my luck at a third-party repair shop if this old fellow breaks again.

Over the years, I’ve spilt milk on it and had to get the motherboard repaired. I dropped it at Connolly Station, thought it was definitely broken, and I literally held my head in my hands on the bench for several minutes. But this old chap has pulled through time and time again. Thanks to its 32 GB RAM, I can at least dip my toes into some small-size LLMs on it. While the lack of Apple Silicon’s unified memory architecture for GPU acceleration and modern ML frameworks like MLX is really a pain in the ass, considering the recent price of RAM, I need it to keep chugging along for a couple more years.

The problem is, it’s not just the lack of hardware repairs, the fading software support is coming back to bite me in the ass too. I even started seeing this issue when I updated using Homebrew:

Error: node: no bottle available!
If you're feeling brave, you can try to install from source with:
  brew install --build-from-source node
This is a Tier 3 configuration:
  https://docs.brew.sh/Support-Tiers#tier-3

This means they are withdrawing support for the pre-built bottles for my old fellow. Although I could download the source code and compile it myself, that would mean more work. And the last thing I want is any hassle. Luckily, I found a workaround. I replaced the current one with node@24 LTS. Click to ignore Homebrew and check out the truly useful masterpiece!

Replacing it is quite simple:

1. Install Node.js 24 LTS:

   brew install node@24

2. Uninstall the unversioned formula:

   brew uninstall node

3. Link node@24 and overwrite any remaining npm files:

   brew link --overwrite node@24

4. Verify the active versions:

   node -v
   npm -v

According to Homebrew, this allows me to cling to life until 30 April 2027. I hope I can afford a new Mac before that time comes, otherwise, this kind of issue will become more and more common in the foreseeable future.

To clean up corrupted or orphaned cache entries and verify integrity without wiping everything, you can run:

npm cache verify

This garbage-collects unneeded index records and repairs corrupted data, though because it preserves all valid cached packages, it won’t free up space taken by older packages you no longer need.

If you are severely low on disk space and truly want to purge all cached packages, the only official way is:

npm cache clean --force

Use this sparingly, however, wiping valid cache entries forces npm to re-download dependencies from the registry on future installs, wasting bandwidth and slowing them down.

The Redemption

Several days later, another message showed up when I used brew upgrade.

Warning: You are using macOS on Intel x86_64.
We do not provide support for this platform (as-of September 2026, announced August 2025).

Apple have dropped Intel x86_64 support in macOS Golden Gate (27).
GitHub Actions are dropping macOS Intel x86_64 runners in 2027.
Homebrew is a non-profit project run entirely by volunteers, not employees.
If the biggest companies in the world cannot support macOS Intel x86_64
any longer, sadly neither can we.

You will have better luck with MacPorts which still supports macOS Intel x86_64:
  https://www.macports.org

I never imagined that Homebrew’s decision to discontinue support for Intel Macs and introduce me to MacPorts would open up a whole new world for me, to the extent that I ended up completely overhauling my development environment. It all started with this note:

nodejs26 does not contain npm but it can be installed as a separate port. Pick from the choices listed by running: port search —name —glob ‘npm*’

I was tired of npm’s cache and node_modules, which are located in each project root folder, eating up a lot of my storage for a long time. But no matter whether I installed Node.js from the official website or Homebrew, npm always came bundled with Node.js. I now know that I can build it from source with only the runtime. However, since there are no instructions on the official landing page or docs, it was hard to realise there was a distinction between the runtime and the package manager back then.

It was then that I quite naturally came across pnpm. pnpm is a fast, disk-efficient package manager for the JavaScript ecosystem, designed as a drop-in replacement for npm.

Compared to npm, its key advantages include:

• Massive Disk Space Savings: It uses a global content-addressable store on your hard drive, hard-linking packages so the same dependency is never duplicated across projects.
• Significantly Faster Installs: By skipping redundant downloads and running tasks concurrently, installs and CI builds are noticeably faster.
• Strict, Phantom-Dependency Prevention: Unlike npm’s flattened node_modules, pnpm uses symlinks to create a strict structure, preventing your code from accidentally importing dependencies you never explicitly declared in package.json.
• First-Class Monorepo Support: It natively handles multi-package workspaces with zero hassle.

That means I don’t need to worry about running npm cache verify, npm cache clean --force, or deleting node_modules manually from time to time to keep my projects consistent and clean. I immediately installed MacPorts, installed nodejs26 and pnpm through it without a second thought, and migrated all my JavaScript projects to pnpm. For me, the way pnpm runs is like magic.

But as I ventured deeper down the rabbit hole, I found something even more shocking: I could even get rid of pnpm! Not by switching to another package manager like Yarn that could be paired with Node.js, but an actual runtime that can replace Node.js and a package manager all by itself! That’s right, with Deno or Bun, not only will you no longer have to worry about which package manager to choose, but you’ll also be able to enjoy a more cutting-edge and faster development environment! If you are interested in the differences between Node.js, Deno, and Bun, you can find a more useful comparison on this page.

In my own experience, I’ve already migrated one of my JavaScript projects totally from Node.js to Deno. All I needed was to replace express, cors, dotenv, and Node-specific http constructs with native Deno APIs. However, while my other two projects focus on TypeScript and should have been better suited to a switch to Deno (given its native support for TypeScript), one uses Electron for its GUI and the other is this blog which relies heavily on Node.js via Astro. After careful consideration, I ultimately decided against migrating them, opting instead to switch to Node.js + pnpm.

A blessing in disguise

The reason I didn’t try Bun is because Deno was already installed on my MacBook as a dependency of yt-dlp. Yep, that is the only reason. Now you know how lazy I am.