sigh.dev - Scott Cooper's dev blog - #typescript

Ending my Angular projects

Sun, 15 Mar 2026 08:00:00 GMT

I am retiring the rest of my Angular libraries. I have already marked many of them as archived or deprecated, but this is the last wave. The issues pile in and I have no reason to maintain them anymore.

What’s weird is that with access to AI, you’d think I’d have more time to maintain them. Or that I could just point an agent at the repo and have it maintain them for me. But what it actually creates is more issues. You still need someone to keep up with the ecosystem and have a vision for the project and understand the nuances of a framework. Should ngx-toastr migrate to Angular signals? How has sass evolved since I launched ngx-toastr? Does shipping a bootstrap stylesheet for toasts even make sense anymore?

Could your agent implement a better toast component in one or two prompts?

The first Angular 2+ and TypeScript commits I found in my repos are from July 28, 2016. I owe much of my career to Angular turning me on to TypeScript, and it’s been a great 10+ years.

Fast-forward to today: I haven’t used Angular in over 5 years, and I don’t see myself shifting back. I’m mostly using React and TanStack Start on side projects. At a certain point, it becomes a detriment to an ecosystem to have half-maintained projects, as the forks can’t thrive. I’m not even sure what version Angular is on anymore.

I got to see some of these libraries make their way into interesting places. ngx-emoji-mart was used in some form in ClickUp, and ngx-toastr was used in the Angular documentation for a while. I also got to see some of these projects get forked and maintained by other people, which is really cool. I hope they continue to thrive.

What I’m Retiring now

ngx-toastr (2.6k★)
ngx-emoji-mart (460★)
ngx-color (444★)
ng2-adsense (139★)

Where should people go now? I’m not sure. Fork it and make your own.

What changed

When I started these libraries, the default move was “install a full component suite,” and you saw libraries like Angular Material and PrimeNG getting millions of downloads. Now the center of gravity is headless primitives plus composition. Teams want control over markup, styling, and behavior instead of inheriting a giant, opinionated package.

AI shifts that default again. More people will type “make a color component” before installing an off-the-shelf color picker. And frankly, they should. For many apps, that generated component is already good enough and faster to adapt.

I still think there’s room for good, battle-tested headless primitives, but the bar is higher.

If you opened issues, sent PRs, or used these packages in production: thanks. I mean that.

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.sigh.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.

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.