fix: pin isbot to 3.x

[brophdawg11]

PR Checklist

• [x] Addresses an existing open issue: reported by Joe in slack 😄
• [x] That issue was marked as status: accepting prs
• [x] Steps in CONTRIBUTING.md were taken

Overview

Fix broken deploys from the isbot@4 - Internal remix entry.server.tsx file relies on isbot@3

[brophdawg11]

So by default you own your entry points (entry.server.tsx, entry.client.tsx), but since they are mostly boilerplate and don’t often need to be customized - you are able to delete them and remix has its own internal implementations (currently using the isbot v3 API). One Joe updated the dep to v4, things went awry since the internal impl still assumes v3 (we’ll be fixing this assumption in the next remix release)

If you run npx remix reveal you’ll see the “normal” setup which removes the “hidden” usage - so that could be more appropriate for a shared repo such as this one where different folks with different levels of Remix familiarity will be contributing.

[tjwds]

One Joe updated the dep to v4, things went awry since the internal impl still assumes v3 (we’ll be fixing this assumption in the next remix release)

That's not quite true — I updated to v4 just to see if that would fix the issue before moving on with my day :-)

I think what happened is:

• The repository got created with "isbot": "latest",
• isBot updated their "latest" to point to v4 today (https://www.npmjs.com/package/isbot)
• Our cron job that regularly rebuilds the site in order to make sure the "up next" events list is correct grabbed this update, which broke stuff!

[brophdawg11]

Oh interesting, my bad. I think I thought we installed latest at app creation but that it left the numerical version in package json after that, not ‘latest’ verbatim. Does pnpm’s lock file not store the v3 version resolved to by ‘latest’? Or does the cron job do a full reinstall and not use the lock file (I.e., npm install versus npm ci)? I’m not too familiar with pnpm.

Aren’t y2k bugs fun?!?