Closed ddbeck closed 2 years ago
This sounds great!
I have a suggestion: I would be glad if the new linter used async I/O. Occasionally, I have to work on limited computers (HDD-based/old/low-power/etc.) and linting becomes a real drag. For reference, (due to circumstances outside of my control) this week I'm working on a computer with Intel Core 2 Duo (launched in 2006, discontinued in 2012). time npm run test
says that real
time is 15 seconds, and sum of user
and system
times is less than 0.25 seconds.
Since https://github.com/mdn/browser-compat-data/pull/16437 had landed, can we close this issue or is there more work to be done?
This can now be closed as completed! 🎉
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:
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 https://github.com/mdn/browser-compat-data/pull/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