🔹 Inspiration

Web developers often want to use modern features like :has(), <dialog>, or the Clipboard API but the real question is: “Can I use this today without breaking users?”
Right now, most people leave their editor, Google MDN or CanIUse, and try to interpret compatibility tables. That slows development and introduces risk.

I wanted to make this instant and trustworthy, by putting Baseline compatibility data directly into the tools developers already use.


🔹 What it does

Baseline Dev Coach is a developer companion that:

  • CLI — scans your codebase for modern features and flags risky ones.
  • VS Code extension — shows Baseline support status on hover, right inside your editor.
  • GitHub Action — runs automatically on pull requests and comments findings for reviewers.

It uses the official web-features dataset, maintained by the W3C WebDX group, so results are authoritative and reliable.


🔹 How I built it

  • Dataset integration: I pulled structured compatibility data from web-features (Baseline dataset).
  • CLI: Built with TypeScript + Node.js, parsing CSS/HTML/JS files using regex scanners.
  • VS Code extension: Registered hover providers that match modern web features and display Baseline status via Markdown tooltips.
  • GitHub Action: Wrapped the CLI into a CI step, piping results into sticky pull request comments for reviewers.

🔹 What I learned

  • How the Baseline dataset is structured and how it differs from traditional “Can I Use” data.
  • How to build and debug a VS Code extension with hover providers.
  • How to run Node.js workspaces inside GitHub Actions.
  • How to demo a project in a way that’s clear, concise, and useful for judges.

🔹 Challenges I ran into

  • Integrating the dataset: web-features is still evolving, so mapping IDs to real-world code patterns required iteration.
  • VS Code hover conflicts: At first, MDN reference hovers overshadowed mine , i had to carefully register providers so our tooltips actually appeared.
  • CI feedback: Getting GitHub Actions to not just run but also comment directly on PRs required digging into community actions like sticky-pull-request-comment.
  • Balance: I had to build a project that was functional and useful but still small enough to finish in hackathon time.

🔹 What’s next

  • Add AST-based scanning for deeper code analysis.
  • Expand feature coverage (e.g. Web APIs beyond the demo).
  • Ship as a published VS Code extension on the marketplace.
  • Provide config options so teams can enforce stricter Baseline policies in CI.

Built With

Share this project:

Updates