Inspiration

The inspiration hit me the moment I read the hackathon's central question: "Ever hesitated to use a new feature...?" I felt that. Deeply. As a web developer, I've spent countless hours jumping between my code, MDN, and CanIUse, trying to answer that exact question. It always felt like a tax on my productivity and creativity.

I didn't just want a tool that would tell me "yes" or "no." I wanted to build the tool I wished I had: a co-pilot that would let me write the most modern code I could, and trust that the tool would make it safe and robust for production automatically.

What it does

So, I built the tool I wished I had. I call it Baseline Vanguard. At its heart, it's a linter that doesn't just complain—it helps.

First, it scans your JavaScript and CSS for features that aren't yet considered "Baseline" (i.e., universally supported). But here's the magic: instead of just flagging an error, its --fix command automatically refactors your code. It adds safe fallbacks for JavaScript and wraps modern CSS in @supports blocks so it just works everywhere.

And for my favorite part, I added a truly innovative rule: it spots when you're using a heavy library like moment.js for something that a native, Baseline API like Intl can now do, helping you ship less code. To showcase all this, I built a live, interactive playground where anyone can paste their code and see the transformations happen in real-time.

How I built it

I knew I needed to keep things organized, so I went with a pnpm monorepo from the start. The core is two separate plugins: one for ESLint (JavaScript) and one for Stylelint (CSS).

The real work was digging into their APIs and learning how to traverse the code's structure (the Abstract Syntax Tree, or AST). All the compatibility data comes directly from the official web-features npm package, so it's always the source of truth.

For the live demo, SvelteKit was a no-brainer—it’s incredibly fast for building interactive UIs. I threw in CodeMirror to give the web editor a professional feel. The whole thing is written in a mix of JavaScript and TypeScript, and I even wrote unit tests with Vitest to make sure the auto-fixing logic was solid.

Challenges I ran into

Oh, the challenges. The auto-fixer logic was a beast at first. My initial version of the .at() fixer was spitting out code that would crash because of a simple variable scope issue (it wrote posts.length instead of user.posts.length). It was a humbling reminder that generating code is way harder than just finding it.

The CSS side was just as tricky. At one point, my Stylelint rule was getting confused and wrapping my entire stylesheet in a giant, invalid @supports block. Debugging the AST traversal to isolate just the one specific rule I wanted to change took a lot of trial and error, but getting it right was a huge breakthrough.

Accomplishments that I'm proud of

Getting the live playground deployed and working was a huge "YES!" moment. Seeing the code transform in a live web app for the first time was incredible.

But honestly, I'm most proud of the bundle-size awareness rule. It felt like a genuinely new idea—connecting browser support directly to real-world performance. It's the kind of smart hint I'd want my own tools to give me every day. Building a project that feels not just useful but truly innovative is what I'm proudest of.

What I learned

This hackathon was a crash course in developer tooling. I went from having a vague idea of how ESLint worked to actually writing my own rules that manipulate the AST. I also learned that building a good UI, even for a developer tool, is critical for showing its value to others. And SvelteKit is definitely my new go-to for projects like this. Most importantly, I learned that the best tools are the ones that remove friction and empower developers to do their best work without fear.

What's next for Baseline Vanguard

This feels like a really strong foundation. The dream would be to build this out even further:

  • Add dozens more rules to cover the full spectrum of web-features data.
  • Publish the ESLint plugin as a real VS Code extension.
  • Create a GitHub Action to automatically check pull requests for compatibility issues.
  • Make the auto-fixer even smarter by suggesting specific polyfills based on a project's browserslist configuration.

Built With

Share this project:

Updates