Baseline Status Indicator

Inspiration

As a web developer, I live in my code editor, but I'm constantly forced to leave it. Every time I use a modern CSS property or JavaScript API, the same question pops into my head: "Is this safe to use yet?" This simple question triggers a familiar, flow-breaking routine: open a browser, search MDN or CanIUse.com, analyze a compatibility table, and then finally make a decision. This "compatibility tax" is a constant drag on productivity for developers everywhere.

The inspiration for the Baseline Status Indicator came from a desire to eliminate this friction. What if that crucial compatibility information was just... there? Right where you're writing the code? The Baseline Tooling Hackathon provided the perfect opportunity and the ideal data source (web-features) to build this dream tool and solve a problem I face every single day.

What it does

The Baseline Status Indicator is a Visual Studio Code extension that provides real-time, in-editor feedback on web feature compatibility. When a developer hovers over a CSS property or JavaScript API, a tooltip instantly appears showing its status according to the Web Platform Baseline standard.

The tooltip provides:

• A clear, icon-based status:
  • ✅ Widely Available
  • ⏳ Newly Available
  • ℹ️ Not Baseline
• The exact date the feature reached that status.
• The official description of the feature to provide immediate context.

It helps developers make informed decisions about the code they write, empowering them to use modern web features with confidence and without ever leaving their editor.

How we built it

The project was built from the ground up as a VS Code extension using TypeScript.

1. Scaffolding: I started with the official yo code generator to create the basic extension boilerplate.

2. Data Integration (and a Pivot): My initial approach involved using the raw @mdn/browser-compat-data package. While powerful, this proved to be incredibly complex to parse. The turning point was discovering the hackathon's official web-features package. Its simple, flat data structure was a game-changer, allowing me to replace dozens of lines of complex tree-traversal logic with a single line of direct object lookup.

3. Core Functionality: The main feature is powered by the VS Code API's registerHoverProvider. This API allows the extension to detect when a user hovers over text. My implementation captures the word under the cursor, looks it up in the web-features data, and then dynamically builds a Markdown-formatted tooltip based on the result.

4. Solving Module Issues: A key technical challenge was the incompatibility between the extension's default CommonJS module system and the modern ESM format of the web-features package. I resolved this by refactoring the activation event to be async and using a dynamic import() call to load the module at runtime.

5. TypeScript Configuration: The final hurdle was a series of TypeScript errors originating from the package's type definitions. After debugging, I found they were incompatible with the project's default tsconfig.json settings. I fixed this by changing the "moduleResolution" from "nodenext" to "node", which made the compiler compatible with the package's type style.

Challenges we ran into

• Module Incompatibility: The biggest roadblock was the CJS vs. ESM conflict. Getting a modern ESM package to work inside a traditional CommonJS-based VS Code extension was challenging and required a deep dive into how Node.js modules work.

• TypeScript Configuration: Debugging errors that came from a dependency in node_modules was difficult. It took time to realize the problem wasn't in my code or the package's code, but in the configuration bridge between them (tsconfig.json).

• Initial Data Complexity: Before switching to web-features, trying to build a universal lookup function for the deeply nested @mdn/browser-compat-data tree was a significant challenge that consumed a lot of initial development time.

Accomplishments that we're proud of

• Building a Genuinely Useful Tool: I'm proud to have built a tool that solves a real, everyday problem for web developers. It's not just a demo; it's something I will use daily.

• Overcoming Technical Hurdles: Successfully debugging the module and TypeScript compatibility issues was a major accomplishment. It required learning and applying a deeper understanding of the modern JavaScript ecosystem.

• A Polished User Experience: The tool feels responsive and intuitive. A key design choice was to not show a popup for unknown or fake properties, keeping the extension clean, focused, and unobtrusive.

What we learned

• The JavaScript Module Ecosystem: I gained a much deeper, practical understanding of the differences between CommonJS and ESM and, more importantly, how to make them work together.

• The Power of Abstraction: The difference in development speed between the raw BCD data and the purpose-built web-features package was immense. It was a powerful lesson in the value of a well-designed API.

• The Devil is in the Config: I learned that sometimes the most difficult bugs aren't in the code you write, but in the configuration files that tell your tools how to interpret it.

What's next for Baseline Status Indicator

The current extension is a fantastic foundation, and I'm excited to build on it.

• Support for HTML: Extend the functionality to provide Baseline status for HTML tags and attributes (like <dialog> or the popover attribute).
• Smarter JS API Detection: Implement a more robust parser (like an Abstract Syntax Tree) to accurately identify complex, multi-part JavaScript APIs
• Configuration Settings: Add user settings to allow developers to target a specific Baseline level and have the extension flag code that doesn't meet their project's requirements.
• Publish to the Marketplace: After some polishing, the ultimate goal is to publish the Baseline Status Indicator to the official VS Code Marketplace for the entire developer community to use.

Built With

• node.js
• typescript
• visual-studio-code-api
• web-features-npm-package