Baseline-Buddy

BaselineBuddy scans your code with the official Baseline dataset to flag safe ✅ and risky ⚠️ web features. Use in CLI, CI, or IDE to save time, avoid bugs, and build modern web apps with confidence.

Comment

🌟 Inspiration

As web developers, we’ve all been burned by compatibility issues.
An API or CSS property works flawlessly in Chrome but completely breaks in Safari or Firefox. This leads to:

  • Hours wasted searching MDN/Can I Use/App support charts.
  • Fear of using modern platform APIs.
  • Slower adoption of powerful new features.

We thought: “Wouldn’t it be awesome if your code could just tell you which features are Baseline‑safe and which still need caution?”
That’s the origin of BaselineBuddy.

⚡ What it does

BaselineBuddy is a lightweight CLI tool that:

  • 🔍 Scans your JavaScript and CSS source files.
  • ✅ Identifies modern web features (e.g. AbortController, IntersectionObserver, :has()).
  • ⚠️ Flags APIs that are not part of the Web Baseline yet (e.g. showOpenFilePicker).
  • 📊 Generates both:
    • Colored console output (great for dev workflow).
    • A Markdown report (baseline-report.md) suitable for CI/CD, PR reviews, or project documentation.

In short: BaselineBuddy says “Green = Go. Yellow = Careful.”

🛠️ How we built it

  • Node.js for portability and ecosystem familiarity.
  • @babel/parser to walk the JavaScript AST and extract identifiers, constructors, and method calls.
  • PostCSS with the safe parser for CSS rule and declaration analysis.
  • web-features dataset for the authoritative Baseline support status.
  • Matching logic combining:
    • Alias mapping (e.g. showOpenFilePicker → File System Access).
    • Fuzzy matching for grouped APIs (IntersectionObserver → Intersection Observer).
    • Noisy identifier blacklist (log, file, window).
  • chalk for green/yellow/gray console feedback.
  • Markdown report generator for human‑readable summaries.

🏔️ Challenges we ran into

  • Mapping mismatch: showOpenFilePicker didn’t exist exactly in the dataset; we had to alias it to File System Access.
  • False positives: Words like log were being matched to math APIs (pow(), sqrt(), log() etc). Fixed with a blacklist.
  • Dataset complexity: Discovered that web-features groups many APIs differently than how developers call them.
  • Time constraints: Balancing core functionality vs. demo polish (console colors, Markdown reporting).

🏆 Accomplishments that we're proud of

  • Got BaselineBuddy working end‑to‑end in a few days: input code → output colorful results + a report.
  • Eliminated noisy false positives with smart alias + fuzzy logic.
  • Produced a tool that judges can run instantly, with no setup confusion.
  • Created a workflow enhancement that could genuinely help web dev teams adopt modern features faster and safer.
  • Wrote a tool we wish existed in our daily developer lives!

📚 What we learned

  • How the Baseline dataset is structured and why features are grouped.
  • Practical AST handling with Babel parser — and how tricky real‑world identifier matching can be.
  • Balancing false positives vs. missed detections (fuzzy vs. strict matching).
  • The value of good developer UX: small improvements like ✅ and ⚠️ symbols, Markdown outputs, and skipping noisy identifiers made huge usability differences.
  • Hackathon teamwork: prioritizing the MVP, then polishing for impact.

(We even applied algorithmic thinking: parsing complexity is roughly 


O(N \cdot M)

Built With

Share this project:

Updates