sigh.dev - Scott Cooper's dev blog - All posts and notes

You can just port things to Cloudflare Workers

Sun, 25 Jan 2026 08:00:00 GMT

This January I decided to double down on using up my free ai credits by building a few projects on Cloudflare Workers. I’ve always really liked the idea of this platform that has cheap/free resources, but every time I build larger things on it I run into limits that make me frustrated and move to cheap vps hosting like fly.io or DigitalOcean.

Is vibeporting a word? Maybe it should be?

Datasette-ts

Over holiday break, I was reading some of Simon Willison’s posts about AI and I checked where it’s currently possible to deploy it. You can deploy it pretty much everywhere but NOT on Cloudflare Workers, due to workers not really supporting much of Python’s ecosystem. I pointed Codex with GPT-5.2 Codex high/medium at the Datasette repo and had it break it down into README tasks and slowly do them one at a time. I’m not yet convinced by the crazy subagent stuff or that worktrees are worth it.

As I got into it, it was clear I needed to narrow down the scope. Mr. Willison has built a very mature project that has a plugin system and a ton of features built-in and it depends on subdependencies that he also has published like sqlite-utils. Obviously, what I wanted is something that feels similar and runs on Cloudflare Workers. I picked up Drizzle, Hono, and Alchemy to handle Cloudflare deployments. I chose not to rebuild the frontend as a React SPA instead rendering something similar to the original Jinja templates using Hono’s JSX.

Anyway, it ends up working pretty well. You can see a live demo at datasette-legislators.ep.workers.dev and the source is available below. I can’t say the code is in a good state, but it lives here https://github.com/scttcper/datasette-ts.

SESnoop

Another Cloudflare Worker port, this time of a Rails app called Sessy. I decided to rename it because I was going for a different vibe. I send a bunch of emails via SES for xmplaylist.com and I was looking into running Sessy to handle the bounces and complaints, however I can’t get myself to think about Ruby for more than 1 minute. So again I pointed Codex at the Sessy repo and a few other Cloudflare/Hono example repos and had it build out a monorepo where the worker handles the api and Cloudflare assets serves a React SPA frontend.

I think what was hard to reel in was how much frontend it was willing to build before I could stop it and start bringing in shadcn components. Like it made a bunch of select components and things that were generally pretty ugly. So then you have to tell it to replace all the ugly things with premade shadcn + baseui components.

This project took a bit more work to get working outside of pointing AI at the code. It made a number of Cloudflare mistakes, tests were difficult to get working 100% correctly. One example was that it put the webhook at /webhook which Cloudflare would attempt to load as an asset since the worker is bound to /api which is always a bit of a headscratcher until you remember how this all works. It was really cool getting to know how SNS works with SES and watching them flow into D1 is fun.

I tried publishing this package to npm and it kinda works to deploy to cloudflare if alchemy is setup. Or you can run it locally with npx datasette-ts@latest serve ./legislators.db

I don’t have a live demo, but you can check out the source code at scttcper/sesnoop.

Conclusion

Pretty happy with how both of these turned out. I didn’t exclusively use Codex on either of them, however Codex was the main driver 95% of the time. I think Codex w/ GPT-5.2 Codex on high or medium is a great model and through the team plan you can basically run medium as long as you want. I exhausted about 1 week worth of the plan I’m on for Codex for each project.

xmplaylist in the wild

Sat, 17 Jan 2026 08:00:00 GMT

I’ve been collecting places where the xmplaylist.com API has shown up in the wild. I always think these are pretty interesting, so here’s a quick roundup of projects I’ve found that are scraping my data or using the API. As always, please use the xmplaylist feed endpoint instead of making 300 requests for all channels. /api/feed

SiriusXM plugin for Lyrion Media Server

GitHub • Forum

This plugin uses the xmplaylist.com API to fetch recent tracks metadata for SiriusXM channels because SiriusXM itself doesn’t expose that track metadata easily. The audio side is completely separate. It uses FFmpeg to demux the HLS streams and feed FLAC to the media server. It started as a Python proxy and was eventually ported to Perl to fit the plugin footprint.

EasyList

GitHub Commit

I finally made it. xmplaylist.com was added to EasyList so adblockers can more aggressively block my ads. Honestly, I’m just happy to be included.

PowerShell module wrapper

GitHub

This XmPlaylist module wraps the API for all you Windows power users. It exposes station lookups and recently played queries directly in your shell. It even includes helpers to format items or play tracks via yt-dlp and ffplay which honestly isn’t a great way to get music, but I’m here for it.

XM → Spotify archiver

GitHub

This is a serverless bot that scrapes recent tracks and archives them into Spotify playlists, running entirely on GitHub Actions via cron. It uses cloudscraper to bypass Cloudflare challenges because I assume the github actions ip addresses are trash or they’ve forgotten to include a user agent. It dedupes tracks locally and even auto-rotates playlists when they near Spotify’s 10,000 track cap. It’s built to self-heal if the local JSON state gets corrupted, which is probably better error handling than I have in my own app.

XM Spotify Sync

GitHub

This Python-based tool bridges the gap between satellite radio and streaming by automatically syncing tracks from XM Radio stations directly to your Spotify playlists. Built with a modern architecture featuring a FastAPI backend and Flask frontend, it handles the heavy lifting of polling station data and updating your playlists in the background. The project is container-ready with Docker Compose and Kubernetes support, making it a robust solution for archiving your favorite radio curation.

Android “playlist hijacker”

GitHub

This one is a standalone Android app scaffold built with Kotlin and Compose. It scrapes XM channel history and mirrors it into private YouTube playlists using the Google Sign-In and YouTube Data APIs. It has some maintenance tools to shuffle items or trim the playlist down to an 80-item cap. The code is a bit rough—there are some TODOs left in key places like the playlist ID mapping—but it’s a cool proof of concept for a mobile-first approach. I appreciate the repo name XMPLAYLISTHIJACKERSTANDALONE, wonderful vibe.

SiriusXM to USB

GitHub

This Python CLI retrieves station data from the API and then scours YouTube Music for matches. The author built it to demonstrate creating a powerful CLI in under a day, complete with multiprocessing and colored logging. It even includes a --download flag.

I’m addicted to free AI credits

Sun, 14 Dec 2025 08:00:00 GMT

You might be too late to enjoy the era of $5 Ubers in SF, but you can still get a ride for free with AI. I’m absolutely hooked on using any available free AI models. Cursor will randomly announce that a new model is free for a week or whatever and I’m fucking there. Remember that time SOTA models were available for free? That was last week, and it’s hard to say how long this sort of spending will continue.

Opus 4.5 was free for a while, and it did get me hooked on the model. I had tried Sonnet 4.5 a number of times but found it annoyingly cheerful and not as good as GPT-5.1 (granted GPT-5.1 came out way later). Now that I’m faced with having to pay for Opus 4.5, I am certainly tempted and I can see why so many are willing to jump on Claude Code.

GitHub’s Copilot is giving me their monthly free open source subscription to a limited Copilot plan. I like how they’re still using the old Cursor pricing billed by requests rather than tokens. You can get quite a few things done with that. Google’s antigravity is interesting, but so far it seems to expire before it gets anywhere. I think the one takeaway from chasing free credits is that all the VS Code forks are now basically the same, assuming they have a plan feature. The furthest behind might be Gemini’s VS Code extension, which is a fairly shit experience. I’ve tried some free models and bounced off because they produce more slop than anything useful. Grok’s models are all shit so far.

What did I build?

I launched a paid plan for xmplaylist.com and improved a number of my open source projects. I’d say the best use of these free credits has been nice little admin pages that I never would have spent time building. I can point the agent at enough examples that it needs hardly any direction to get it done. I only really do TypeScript in my free time and I’m sometimes jealous of the Django admins in other languages. Slop together a similar admin with TypeScript and drizzle and you’ve likely got a better dev experience than any Django app.

I’m sure the free tokens will be locked down soon. I’m riding around as much as I can.

Some random predictions for 2027:

People will use smaller models to save money and because they’ve caught up in performance. I’m hopeful for Gemini 3 Flash and not hopeful for SOTA getting cheaper.
Cursor will have to drop the price on their composer-1 model (which works great)
At least 2 more VS Code forks will launch
I’ll still be chasing free SOTA models
Grok will continue to be 2nd rate
I’ll actually pay for a personal plan from some provider

TODO:

try windsurf

How I Use Hono and Tanstack Start

Thu, 20 Nov 2025 08:00:00 GMT

I’ve never liked using any of the fullstack web frameworks for apis. They lack clear middleware and routing, they never quite support openapi and the types are often more difficult to work with. I see lots of people use tRPC or oRPC to try to smooth out the rough edges, but most of my side projects rely on heavy caching and RPC is inheirtly shit at caching at the CDN lavel because it makes post requests. Nextjs is the worst offender here, api middleware is a complete nightmare to understand.

The two options for using hono as I see it are:

Use vite to start a hono server that loads tanstack start. This was popular how most remix+hono projects tend to be structured.
Use tanstack start to route api requests to a hono server. This is the pattern I’ve been using for a while now and it’s working well for me.

Hono up front

I see the appeal of using hono up front to do all routing, you can inject everything you want and have the last word on the request/response via middleware. https://github.com/bskimball/tanstack-hono shows this off really well. I think the main tradeoffs here are that you have a way more custom vite config and a bit more of a custom build process which might be difficult to maintain especially as tanstack continues to iterate on the vite plugin leading up to the stable release. You’ll notice it runs npm run build:client && npm run build:server && npm run build:types to build which creates different bundles via vite.

Hono in the back

I like to have hono sit in the back during development and then bring it to the front in production, which is a little funky but you only need to set up the production side once. The advantage here is that you don’t need to customize the vite config. Tanstack start can pass requests to hono via an api wildcard route.

// src/routes/api/$.ts wildcard api route
import { createFileRoute } from '@tanstack/react-router';

import { app } from '../../../server/app';

const serve = async ({ request }: { request: Request }) => {
  return app.fetch(request);
};

// Route all api requests to the hono server
export const Route = createFileRoute('/api/$')({
  server: {
    handlers: {
      GET: serve,
      POST: serve,
      PUT: serve,
      DELETE: serve,
      PATCH: serve,
      OPTIONS: serve,
      HEAD: serve,
    },
  },
});

My Favorite NPM Command

Sat, 11 Oct 2025 08:00:00 GMT

Let’s talk about my favorite npm command, npm repo.

Open package repository page in the browser - npm docs

This command is dead simple. Open the repository page for the given package in the browser. If you omit the package name, it will look at the local package.json and open that repository.

I use this command several times a day—often hourly. What’s great is that it works for published npm packages and any repo with a package.json. I’ll use it just to open the repo I’m working in, too. I don’t need a bunch of bookmarks or to hope that my current repo shows up on the GitHub homepage. I’ll just run npm repo and dig into any package, and I’ve yet to be rickrolled. Googling certain packages is annoying because you often have to add “GitHub repo” to the search.

History

The npm repo command was added in 2013 in commit 0223389 by TJ Holowaychuk, creator of Express, Mocha, and other popular npm packages. Ignoring various issues opened on the CLI, this is the only contribution he made directly.

Other package managers

The yarn cli does not have a repo command. Pnpm does not have a repo command, instead they forward the command to the npm cli among a list of other commands they forward. pnpm home is another good one they forward to npm, I just don’t usually reach for that one.

As I move further away from using Koa, Express, and TJ’s other legacy projects, I’m positive I’ll keep using npm repo. Praise TJ.

@ctrl/tinycolor Supply Chain Attack Post-mortem

Tue, 16 Sep 2025 08:00:00 GMT

TL;DR

A malicious GitHub Actions workflow was pushed to a shared repo and exfiltrated a npm token with broad publish rights. The attacker then used that token to publish malicious versions of 20 packages, including @ctrl/tinycolor.

My GitHub account, the @ctrl/tinycolor repository were not directly compromised. There was no phishing involved, and no malicious packages were installed on my machine and I already use pnpm to avoid unapproved postinstall scripts. There was no pull request involved because a repo admin does not need a pull request to add new github actions.

GitHub/npm security responded quickly, unpublishing the malicious versions. I followed by releasing clean versions to flush caches, as advised.

For broader context, see Socket’s write-up or StepSecurity’s analysis. For community discussion, see this Hacker News post, which spent 24 hours on the front page. I’m also finding this wiz.io post helpful.

How I Found Out

On September 15 around 4:30 PM PT, Wes Todd DM’d me on Bluesky and looped me into the OpenJS Foundation Slack. By that point, Wes had already alerted GitHub/npm security, who were compiling lists of affected packages and rapidly unpublishing compromised versions.

Early guidance (attributed to Daniel Pereira) was to look for suspicious Shai-Hulud repos or branches. I wasn’t able to find any of these repos or branches on my own personal repos. The mystery was: how was I impacted at all?

Shai-Hulud was the Fremen term for the sandworm of Arrakis. - dune wiki

What Actually Happened

A while ago, I collaborated on angulartics2, a shared repository where multiple people still had admin rights. That repo still contained a GitHub Actions secret — a npm token with broad publish rights. This collaborator had access to projects with other people which I believe explains some of the other 40 initial packages that were affected.

A new Shai-Hulud branch was force pushed to angulartics2 with a malicious github action workflow by a collaborator. The workflow ran immediately on push (did not need review since the collaborator is an admin) and stole the npm token. With the stolen token, the attacker published malicious versions of 20 packages. Many of which are not widely used, however the @ctrl/tinycolor package is downloaded about 2 million times a week.

GitHub and npm security teams moved quickly to unpublish the malicious versions. I then re-published fresh, verified versions of the packages I maintain to flush caches and restore trust.

Impact

Malicious versions of several packages — including @ctrl/tinycolor — were briefly available on npm before removal. Installing those compromised versions would have triggered a postinstall payload, which is documented in detail by StepSecurity.

What should you do if you’ve installed a compromised version of a package? see StepSecurity’s immediate actions.

Publishing Setup & Interim Plan

I currently use semantic-release with GitHub Actions to handle publishing. The automation is convenient and predictable. I also have npm provenance enabled on many packages, which provides attestations of how they were built. Unfortunately, provenance didn’t prevent this attack because the attacker had a valid token.

My goal is to move to npm’s Trusted Publishing (OIDC) to eliminate static tokens altogether. However, semantic-release integration is still in progress: npm/cli#8525.

For the forseeable future, @ctrl/tinycolor requires 2FA for publishing, and all tokens have been revoked. Not expecting to merge any new changes anytime soon.

For smaller packages, I’ll continue using semantic-release but under stricter controls: no new contributors will be added, and each repo will use a granular npm token limited to publish-only rights for that specific package.

Local 2FA based publishing isn’t sustainable, so I’m watching OIDC/Trusted Publishing closely and will adopt it as soon as it fits the workflow.

I plan to continue using pnpm that prevents unapproved postinstall scripts from being run and I’ll look into adding pnpm’s new minimumReleaseAge setting.

Publishing Wishlist

If I could wave a magic wand and design my ideal setup, npm would allow me to require Trusted Publishing (OIDC) with a single toggle for all of my packages. That same toggle would block any release missing provenance, enforcing security at the account level. I’d also want first-class semantic-release support with OIDC and provenance so no static tokens are ever needed.

On top of that, I’d like a secure, human-approved publishing option directly in the GitHub UI: a protected workflow_dispatch flow that uses github 2FA approval to satisfy 2FA, without requiring me to publish from my laptop.

GitHub Environments — or equivalent workflow protections — should be available without a Pro subscription, or else integrated directly into Trusted Publishing so that security doesn’t depend on the pricing tier.

It would be really nice if NPM also had a more visible mark on the package details page to indicate if the package had a postinstall script. Also, once the packages are pulled its not clear what versions were removed and why.

Thanks

Thanks to Wes Todd, the OpenJS Foundation, and the GitHub/npm security teams for their rapid and coordinated response. Everyone was incredibly fast, helpful, and knowledgeable.

Starting a blog

Mon, 01 Sep 2025 08:00:00 GMT

Who?

I work at Sentry.io where I add my cursor generated slop (more on that soon) to their React SPA. Outside of work, I’ve made xmplaylist.com, a music discovery and song tracking app for Sirius XM which runs on Tanstack Start + hono, my current favorite stack. This blog is built with Astro which I’ve never used before.

Why sigh.dev?

My name is Scott Cooper. If you google my name, you’ll find a movie director or a baseball player. My name is essentially annonymous on the internet which can be great. scottcooper.dev is literally owned by someone that seems to do the same thing as me. The sigh.dev domain name is short and sad which is great. The blog theme is currently inspired by soloraized blue theme, weirdly I don’t use that theme. My favorite theme is Dracula + Menlo font. You can actually buy Dracula pro now? But should you?

Slightly more about me

I’ve been a developer for 10+ years, mostly worked at startups that have run out of money. I once helped send over a billion emails in a 24 hour period and this was not an accident. I watch a lot of movies, especially horror movies, some even by director Scott Cooper. I’ve been trying to do a better job of leaving reviews on my letterboxd profile this year.

Diving in

I’m an idiot in San Francisco, but I’ve figured out TypeScript and you’re going to hear about it. If you want updates, subscribe to the posts RSS.

Test Note

Thu, 05 Jun 2025 03:29:00 GMT

I’ve not figured out how much I’ll use notes. They have their own RSS feed at /notes/rss.xml separate from the blog.