Check JavaScript code compatibility with target browsers and Node.js versions

Checks that the language features used in your code/bundles are supported by your browserslist targets.

• check-es-compat - standalone CLI tool
• eslint-plugin-ecmascript-compat - ESLint plugin

You might not need a transpiler or polyfills.

Or, you may be transpiling your own code but not prebuilt 3rd-party libraries - leaving you open to breakages when they use new language features.

ESLint supports targeting a specific ECMAScript version, and eslint-plugin-es-x allows forbidding individual language features. However when building applications, what we target are particular browser/runtime versions. This project lets you check compatibility by specifying those targets directly via a browserslist. It will figure out which individual features you can use, by looking up those targets in the MDN compatibility dataset.

If you're not using a transpiler, run the tool/linter on your source code to ensure you're not using language features that aren't supported in your application's supported browsers.

If you transpile your own code but not 3rd party libraries, run the tool/linter on your output bundles to ensure they're not using language features that aren't supported in your application's supported browsers.

ECMAScript language features only; this includes syntax, built-ins, and methods.

It doesn't check browser/runtime-specific APIs (see eslint-plugin-compat), or CSS (see doiuse).

• ✅ ES2023
• ✅ ES2022
• ✅ ES2021
• ✅ ES2020
• ✅ ES2019^{1, 2}
• ✅ ES2018
• ✅ ES2017
• ✅ ES2016
• ⛔ ES2015 (ES6)³
• ⛔ ES5⁴

We use a pinned version of @mdn/browser-compat-data, because their SemVer policy allows for breaking changes to the data structure even in minor and patch releases. If you need to use more up to date data, use the overrides facility of package.json to specify a later version - but be aware that it might break.

Because JavaScript is untyped, detection of some features' usage (namely prototype methods) through static analysis requires some assumptions to be made. This shouldn't be a problem as long as you avoid creating your own methods having the same names, or write code in an unusual way to deliberately evade detection.

Support can only be checked for the browsers and runtimes covered by the MDN compatibility dataset.

The MDN compatibility dataset has very good feature coverage of the top ~6 desktop and mobile browsers, and Node.js (much more than kangax/compat-table). In case of missing data for a feature (support unknown, or unknown in which version support was added), we currently assume support.

Contributions and feedback welcome. Please see the GitHub issues or create one, as appropriate.

• eslint-plugin-compat - for browser APIs
• doiuse - for CSS
• eslint-plugin-es-x (formerly eslint-plugin-es)*
• @mdn/browser-compat-data*

* Thanks to these projects in particular (and many others) for making this project possible.