Summary

The current BCD linter is very limited; it doesn't (and cannot) check several things which impede data quality improvements. Starting a new linter, based on what we've learned from projects such as Stumptown and standalone BCD tests, can bring many benefits to consumers in the form of data quality improvements, such as:

• Consistency up and down the tree (rather than only per source file)
• Consistency across the tree (e.g., checking consistency between HTML attributes and DOM reflected attributes)

With the existing tools, these quality improvements are high risk to achieve.

Moreover, this would have substantial benefits for authors and contributors, reducing friction in contributing new data or making improvements.

Background

BCD's linter is long in the tooth. It grew from a time when we had lower expectations about what compat data would look like and how we'd work with it. With increasing automation and quality, it's no longer meeting our needs.

Unfortunately, its existing design makes it very difficult to change and improve. It has a number of problems, such as tight coupling, redundant code, and extremely limited test coverage. Even simple bugs require substantial excavation to fix; see mdn/browser-compat-data#12673 as an example.

I've written a high-level design doc for a new linter for BCD, which could make use of developments that emerged after BCD's original linter's design cemented, such as our suite of utility functions, Mocha tests, and more.

Prioritization criteria

• Effort
  • This is somewhat flexible. A greater time investment will yield more checks and features; a small MVP that implements one consistency check could be completed in a small number of days.
• Dependencies
  • Needs somebody with familiarity with BCD, Node.js development. Likely Florian or Vinyl.
  • Needs code review. Likely me or Florian, again.
• Community enablement
  • Helps contributors add better data to BCD
  • Not very easy to involve the community in the initial development, however
• Momentum
  • This is a new effort, though BCD has substantial reliance factors
• Enabling learners
  • Not really applicable. Learners are generally unconcerned with compat issues; they need to support their browser, not all browsers.
• Enabling professionals
  • Significant. Developers need reliable information on which browsers support various APIs, CSS properties, etc.
• Underrepresented topics / ethical web
  • Not applicable.
• Operational necessities
  • Not applicable.
• Addressing needs of the Web industry
  • BCD data is widely used on MDN, caniuse, VS Code, and elsewhere. Far reaching in this area.