If you spend your time in open-source mailing lists or arguing about AST transformations on social media, the recent push toward “erasable syntax” makes total sense.

I’ve been a proponent of TypeScript for a long time. In the early days, whenever someone brought up enum, for example, I remember having conversations along the lines of: “Oh, enum? That’s not real. That gets magically transformed into real JavaScript behind your back.”

And then I’d get a sparkle in wondering what IIFE monstrosity the compiler invented just to make it work. (I have to shout out Ben Alman, who was right here in our ridiculous Boston front-end scene when he popularized the term “IIFE” back in 2010. Little did Ben know the TypeScript compiler would end up weaponizing his naming contribution to haunt us sixteen years later.)

Back then, we loved pulling back the curtain. Do people even know what a polyfill is anymore? I have my doubts.

The thing is, most developers writing code for a living don’t live in that world.

“AST what?”

In the enterprise trenches, where teams were dragged out of desktop software and backend services into the chaotic swamp of modern web development, TypeScript wasn’t viewed as a lightweight annotation layer. It was viewed as a sanctuary.

Anders Hejlsberg designed C#, and then he designed TypeScript. To millions of backend engineers, TypeScript felt like fruit from the very same design tree. The mental model was simple: TypeScript was the bigger circle in the Venn diagram—the “typed superset” Microsoft explicitly sold us. You wrote enum, you wrote namespace, you wrote constructor parameter properties, and you trusted the compiler magic to handle the messy JavaScript plumbing underneath.

And for a decade, that compact worked fine. The build toolchain absorbed the weirdness, emitted runtime IIFEs, and everyone went about their day.

Then the enterprise joined the chorus asking for the holy grail: “Can Node please just run TypeScript natively?”

We got what we asked for. Node will execute your .ts files. But it does so with a massive asterisk that is going to bewilder anyone who learned TypeScript as “C# for the browser”: Node only strips types. It does not compile your bespoke runtime features.

The moment you run a raw TypeScript file in Node without a build step, that comfortable superset abstraction collapses. You have an enum sitting in an enterprise shared-utility file? Crash. A clever namespace? Crash.

Nobody in a corporate sprint planning meeting thought about the distinction between type-stripping and transpilation. They just assumed native TypeScript meant the engine would run their TypeScript code. Period.

Which brings us to erasableSyntaxOnly: true.

JSON

{
  "compilerOptions": {
    "erasableSyntaxOnly": true
  }
}

This flag is essentially the antidote to a decade of superset marketing. It forces the compiler to yell at you the second you write syntax that can’t be deleted with an eraser. Try to write an enum? It breaks in your editor before it can blow up your server.

It is a fascinating full-circle moment. For ten years, teams embraced TypeScript precisely because it felt like a richer, more familiar programming language than JavaScript. Now, if we want the dream of zero-build native execution, we have to teach those same teams that the extra features they loved were actually technical debt in disguise.

Fun times.

A couple of weeks ago, I talked about the “Happy Path Trap”—how LLMs create massive Day 1 velocity while burying teams in silent Day 2 architectural debt.

During that discussion, I pitched an idea: What if we required an Assumptions & Constraints Manifest (ACM) in every AI-assisted PR to make hidden trade-offs visible?

Since I’m not one to wait around for someone else to build tooling I want to use, I spent the last few days building it out.

Today, I’m open-sourcing ACM v1.1—a formal spec and developer toolkit designed to audit architectural boundaries, not just syntax.

What’s in the toolkit:
Typed Contracts & Proof Obligations: Requires the PR to explicitly state guarantees around concurrency, idempotency, and scaling—citing exact line numbers and locking mechanisms.

Automated Generation: Drop-in .cursorrules and PR templates that prompt Cursor, Claude, and Copilot to generate manifests automatically during code creation.

CI/CD Linter: An open-source CLI linter (@roblarsen/acm-cli) and GitHub Action to validate manifests and gate PRs automatically in your pipeline.

Instead of spending 45 minutes playing digital archaeology on AI-generated diffs, reviewers can audit explicit boundaries in 30 seconds.

Get Started
GitHub: github.com/roblarsen/ACM

CLI: npx @roblarsen/acm-cli

• CSS Weaponized at Black Hat 2026: Security researcher Gareth Heyes dropped a research paper showing how CSS alone can break out of webmail sanitizers. Without a single line of JavaScript, malicious stylesheets in Gmail and Outlook were manipulated to spoof UI elements, capture keystrokes, and steal tokens. Stripping <script> tags isn’t cutting it anymore, apparently.
• The 2026 State of CSS Results Are In: The survey numbers show :has() leading as the most used newer feature, while Anchor Positioning holds the crown as the “favorite feature we wish had better browser support.” On the workflow front, 80% of developers report using AI for less than half of their CSS work. It turns out layout still needs humans!

Maintenance of the existing projects is vital, but passive stewardship isn’t enough for where I’m at right now. The web changes too quickly. AI is generating incredible volumes of code and that influx of bloated, unoptimized code requires a counterweight of strict engineering discipline.

So this week, I decided to expand the footprint of @h5bp to act as an active open-source incubator for new projects and emerging engineering talent.

Why an Incubator?

Throughout my career leading engineering teams, mentoring builders has been the most rewarding work I’ve done. The open-source world can be incredibly daunting for a developer looking to scale a project from a personal repository to an industry standard.

By incubating projects within H5BP, we aim to provide independent creators with the operational framework, automation experience, and community visibility required to build high-integrity open source software at scale.

Enforcing Strict Governance

We have just released our Project Inclusion Guidelines. To be considered for the incubator, a project must demonstrate:

• Permissive Licensing: Strict MIT alignment.
• Lean Architecture: Minimal or zero runtime dependencies to protect performance budgets.
• Supply Chain Security: Clean, verifiable dependency graphs to limit organization-level vulnerability.

Submit a Proposal

If you are engineering modern web utilities, or foundational developer tools under strict architectural constraints, we want to hear from you.

Review our new PROPOSAL_GUIDELINES.md, check out the active PR, and submit your Request for Comments (RFC) directly in our meta repository.

Let’s build the next generation of web infrastructure.

On June 17, 2026, a sophisticated supply chain attack systematically poisoned the @mastra npm organization. Over a tight 88-minute window, a hijacked contributor account mass-published 144 malicious package versions. The target wasn’t random. Mastra is a leading open-source TypeScript framework for building AI agents and retrieval-augmented generation (RAG) pipelines. By definition, its packages run in environments dripping with high-value infrastructure secrets: OpenAI keys, AWS tokens, database connection strings, and production CI/CD access.

The problem here wasn’t a sloppy, front-facing exploit. The framework’s actual source code remained pristine. Instead, the attackers pushed the payload one level down into the dependency tree, injecting a typosquatted package named `easy-day-js` (a clone of the ubiquitous `dayjs` date library). Hidden inside an obfuscated `postinstall` lifecycle hook was a cross-platform Remote Access Trojan (RAT). The second it was pulled down, it disabled TLS validation, established OS-level login persistence across Windows, macOS, and Linux, and silently opened a remote execution tunnel.

That’s not great.

Because it executed during the standard `npm install` phase before a single line of application code was even imported, it sidestepped traditional static analysis and CVE-based scanners.

The Yin/Yang of Modern Tooling

This debacle isn’t an isolated incident or an “AI security” problem. It is a direct symptom of the foundational double-standard that splits the tech community in half.

On one side, you have willful blindness. This is the camp that looks at a massive dependency tree and thinks “something bad will happen to someone, someday, but it probably won’t happen to me.”

I am in this camp and am one of the few people I know who will say the words out loud in polite company.

We lock our production systems behind layers of enterprise security, yet blindly execute unvetted code straight on our local developer laptops every Tuesday afternoon. Because it’s probably going to be fine. And we nee to fix this stupid bug.

On the other side sits pure ignorance. There are two flavors of ignorance at play. The first are people which might be in IT, writ large, who don’t really know how npm works and what actually happens when you type `npm install.` The second is the camp that operates under a warm, fuzzy blanket of open-source idealism: “It’s open-source, which means thousands of eyes have already vetted the code, right?”

The reality is that nobody is auditing nested dependency metadata on a random weeknight. Or, really, ever. It all changes so fast.

This is the inescapable Yin and Yang of our modern web architecture. We want velocity. We want to pull down 1,000 dependencies with a single command so we don’t have to write custom date parsers or whatever. But the price of that convenience is an aggressively expanded attack surface.

Yay

When we treat software identity as a proxy for absolute trust, we don’t just inherit the library—we inherit the security habits of every human who has ever touched its dependency graph over the last five years.

It’s what we do and what we’re going to continue to do, but by treating lockfiles like static grocery lists we are simply playing the world’s worst game of security roulette.

Where does this land on the Leaderboard?

In the grand pantheon of npm registry disasters, Mastra ranks highly. It’s a state actor, which is always fun. It lacks the sweeping, internet-snapping devastation (or the lol-factor) of the 2016 left-pad tantrum, and it didn’t achieve the sheer global blast radius of the September 2025 Phishing Wave that hijacked foundational blocks like chalk and debug to drain crypto wallets globally.

Instead, Mastra is an echo of the infamous 2018 event-stream compromise. It proves that the modern threat matrix has expanded away from noisy, registry-wide vandalism. Today’s actors are playing a quiet game of social engineering and credential harvest—hiding their payloads exactly where they know developers are too hurried, too comfortable, or too blind to look.