Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/robatwilliams/es-compat

Check JavaScript code compatibility with target runtime environments
https://github.com/robatwilliams/es-compat

browser browser-compat-data browserslist caniuse checker compat compatibility ecmascript es eslint eslint-plugin-compat eslint-plugin-es eslintplugin javascript kangax lint support

Last synced: about 2 months ago
JSON representation

Check JavaScript code compatibility with target runtime environments

Awesome Lists containing this project

README

        

[![npm version](https://badge.fury.io/js/eslint-plugin-ecmascript-compat.svg)](https://badge.fury.io/js/eslint-plugin-ecmascript-compat)
[![npm downloads](https://img.shields.io/npm/dm/eslint-plugin-ecmascript-compat.svg)](http://www.npmtrends.com/eslint-plugin-ecmascript-compat)

# es-compat

> 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](https://github.com/browserslist/browserslist) targets.

## Tools

- [check-es-compat](/packages/check-es-compat/README.md) - standalone CLI tool
- [eslint-plugin-ecmascript-compat](/packages/eslint-plugin-ecmascript-compat/README.md) - ESLint plugin

## Rationale

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](https://eslint.org) supports targeting a specific ECMAScript version, and [eslint-plugin-es-x](https://github.com/eslint-community/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](https://github.com/mdn/browser-compat-data).

## Usage scenario examples

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.

## Scope

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

It doesn't check browser/runtime-specific APIs (see [eslint-plugin-compat](https://github.com/amilajack/eslint-plugin-compat)), or CSS (see [doiuse](https://github.com/anandthakker/doiuse)).

## ECMAScript version coverage

- ✅ [ES2023](https://pawelgrzybek.com/whats-new-in-ecmascript-2023)
- ✅ [ES2022](https://exploringjs.com/impatient-js/ch_new-javascript-features.html#new-in-es2022)
- ✅ [ES2021](https://v8.dev/features/tags/es2021)
- ✅ [ES2020](https://v8.dev/features/tags/es2020)
- ✅ [ES2019](https://flaviocopes.com/es2019)1, 2
- ✅ [ES2018](https://flaviocopes.com/es2018)
- ✅ [ES2017](https://flaviocopes.com/es2017)
- ✅ [ES2016](https://flaviocopes.com/es2016)
- ⛔ [ES2015 (ES6)](https://flaviocopes.com/es6)3
- ⛔ ES54

n Expand for footnotes...

1 Excluding features not statically detectable: revised `Function.prototype.toString`, stable `Array.prototype.sort`, well-formed `JSON.stringify`.

2 Excluding `Symbol.prototype.description`; as a debug feature, it's not worth the false positives that arise due to its name and not being a method.

3 ES2015 (ES6) is out of scope; it's been [supported](https://caniuse.com/#feat=es6) by evergreen browsers for many years. Assisting you to continue supporting [IE11](https://death-to-ie11.com/) is not a goal of this tool.

4 ES5 is out of scope; it's over 10 years old and [supported](https://caniuse.com/es6#feat=es5) even in IE10.

## Browser compatibility data

We use a pinned version of `@mdn/browser-compat-data`, because their [SemVer policy](https://github.com/mdn/browser-compat-data#semantic-versioning-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.

## Limitations

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](https://github.com/mdn/browser-compat-data/tree/main/browsers) 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](https://github.com/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.

## Contributing

[Contributions](CONTRIBUTING.md) and feedback welcome. Please see the GitHub issues or create one, as appropriate.

## Related

- [eslint-plugin-compat](https://github.com/amilajack/eslint-plugin-compat) - for browser APIs
- [doiuse](https://github.com/anandthakker/doiuse) - for CSS
- [eslint-plugin-es-x](https://github.com/eslint-community/eslint-plugin-es-x) (formerly [eslint-plugin-es](https://github.com/mysticatea/eslint-plugin-es))\*
- [@mdn/browser-compat-data](https://github.com/mdn/browser-compat-data)\*

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