Baseline Developer Tools

Inspiration

I was tired of constantly switching between my code editor and "Can I Use" to check browser support. Every time I wrote a CSS property, I had to stop, open a browser, search for compatibility, and interpret those colorful tables. I thought: "Why can't my development tools just tell me if something is safe to use?" That's when I discovered Chrome's Baseline initiative and realized I could build tools that bring this knowledge directly into my workflow.

What it does

Baseline Developer Tools brings real-time browser compatibility checking into your development environment. I built three integrated tools:

ESLint Plugin: Automatically scans my CSS code and warns me when I use features that aren't Baseline-approved. It checks not just properties, but also specific values like color: oklch(...) or aspect-ratio: 16/9.

Interactive Demo: A web interface where I can paste CSS and instantly see which features are safe to use. It shows me exactly which properties are Baseline, newly available, or limited support - with direct links to documentation.

CI/CD Integration: My GitHub Actions workflow now catches compatibility issues before deployment. It prefetches the latest Baseline data and runs automated checks on every commit.

The system uses Chrome's authoritative Baseline API and cross-references multiple data sources (web-features, WebStatus) to give me accurate, up-to-date compatibility information.

How I built it

I started with the Baseline API and built a cascading validation system:

1. Data Pipeline: I created a prefetch script that pulls the latest Baseline data from web-platform-dx.github.io and caches it locally. This runs in CI before every lint check.

2. ESLint Plugin: I built a custom ESLint rule that parses CSS-in-JS files, extracts properties and values using regex, then checks them against four data sources in priority order: exceptions.json (overrides), compute-baseline library, web-features package, and the WebStatus cache.

3. Value-Level Validation: The hardest part was checking not just properties like color, but also specific values like oklch(). I implemented pattern matching that understands CSS syntax - distinguishing between display: grid (Baseline) and display: contents (not Baseline).

4. Interactive Demo: I used CodeMirror to create a live code editor with syntax highlighting. The demo runs the same validation logic in the browser using local data files, showing results in real-time as you type.

5. GitHub Pages Deployment: I automated the deployment process with gh-pages, so the demo is always accessible for testing and demonstration.

Challenges I ran into

ESLint 9 Migration: I started with ESLint 8's .eslintrc format, but ESLint 9 requires flat config. I had to completely restructure my configuration and figure out how to properly register the plugin in the new format.

Source Location Mapping: ESLint requires precise line/column locations for warnings. My regex matches gave me character indices, so I had to implement sourceCode.getLocFromIndex() to convert indices to proper source locations.

Multi-Source Data Synchronization: Different data sources have different formats and update schedules. I built a fallback cascade that tries compute-baseline first (most authoritative), then web-features (comprehensive), then WebStatus cache (broad coverage), with smart heuristics as a final fallback.

Value-Level Granularity: Checking color: oklch() is different from checking color: red. I had to parse CSS values, handle vendor prefixes, and understand property-specific syntax to make accurate assessments.

Accomplishments that I'm proud of

✅ It actually works: I can paste real production CSS, and it correctly identifies which features are Baseline-approved. The validation is accurate and actionable.

✅ Value-level precision: My tool doesn't just say "color is Baseline" - it knows that color: oklch() specifically isn't widely available yet.

✅ Multi-source intelligence: By combining four different data sources with a smart fallback system, I achieved more comprehensive coverage than any single source provides.

✅ Fully automated: The entire workflow runs in CI with zero manual intervention. Fresh Baseline data is fetched automatically, and developers get immediate feedback on pull requests.

✅ Interactive demo: I built a polished web interface that makes the tool accessible to anyone - no installation required. Judges can test it right now at the live URL.

What I learned

ESLint internals: I dove deep into how ESLint parses code, reports warnings, and integrates with editors. I learned about the AST (Abstract Syntax Tree), source location mapping, and the rule development lifecycle.

Baseline API complexity: The Baseline specification is more nuanced than I expected. There's "widely available" (3 years + 30%+ usage), "newly available" (all browsers but recent), and various edge cases for features that are partially implemented.

Data source reliability: No single data source is perfect. compute-baseline is most authoritative but has limited coverage. web-features is comprehensive but sometimes outdated. WebStatus has broad coverage but includes experimental features. I learned to cross-reference and prioritize.

CI/CD optimization: I discovered that prefetching data once per workflow (instead of per job) saves significant time and API requests. Caching strategies make a huge difference in CI performance.

What's next for Baseline Developer Tools

VS Code Extension: I have a stub implementation but want to complete the full extension with inline warnings, hover tooltips showing Baseline status, and quick fixes suggesting alternatives.

Auto-fix suggestions: When my tool detects a non-Baseline feature, it could suggest alternatives. For example, if I use aspect-ratio, it could offer the padding-bottom hack that works everywhere.

Custom Baseline targets: Let developers configure their own browser support matrix. Some teams might want "Baseline + Safari 14" or "Baseline + IE11 fallbacks."

npm package publication: Make the ESLint plugin installable via npm install eslint-plugin-baseline so other developers can use it in their projects.

Webpack/Vite/Rollup plugins: Extend the checking to build time for CSS files, SCSS, PostCSS, and other CSS preprocessing workflows.

Real-time collaboration: Build a team dashboard showing which non-Baseline features are being used across all projects, helping teams make informed decisions about progressive enhancement strategies.

Built With

• css
• javascript