eslint vs js-beautify vs prettier vs standard

コード品質とフォーマットツールの比較：ESLint、Prettier、Standard、js-beautify

eslint、js-beautify、prettier、standard は、すべて JavaScript コードの品質維持やスタイル統一に使用されるツールですが、それぞれのアプローチと目的が異なります。eslint は主にコードのバグ発見や複雑なルール適用に特化したリンターであり、高い拡張性を持ちます。prettier はコードフォーマットに特化し、設定を最小限に抑えて一貫したスタイルを強制します。standard は ESLint をベースにした意見の強いスタイルガイドで、設定なしで運用できます。js-beautify は歴史のあるコード整形ツールですが、近年は Prettier に取って代わられつつあり、特定のレガシー環境や非 JavaScript ファイルの整形に使われることがあります。

npmのダウンロードトレンド

3 年

GitHub Starsランキング

統計詳細

パッケージ	ダウンロード数	Stars	サイズ	Issues	公開日時	ライセンス
パッケージ	ダウンロード数	Stars	サイズ	Issues	公開日時	ライセンス
eslint	0	27,311	2.91 MB	111	12日前	MIT
js-beautify	0	8,973	982 kB	463	1年前	MIT
prettier	0	51,965	8.6 MB	1,405	1日前	MIT
standard	0	29,430	164 kB	128	2年前	MIT

コード品質とフォーマットツールの深層比較：ESLint、Prettier、Standard、js-beautify

JavaScript エコシステムにおいて、コードの品質を保ち、スタイルを統一することは、メンテナンス性とチームコラボレーションの鍵となります。eslint、js-beautify、prettier、standard はいずれもこの課題に取り組むツールですが、その哲学と技術的なアプローチは大きく異なります。本稿では、これら 4 つのツールを技術的な観点から深く比較し、プロジェクトに適した選択を行うための指針を提供します。

🎯 核心となる哲学：リンティング vs フォーマット

これらのツールを大別すると、「コードの誤りやパターンを検出するリンター」と「コードの見た目（空白や改行）を整えるフォーマッター」に分類できます。

eslint は、コードの品質管理に重きを置いたリンターです。

構文エラーだけでなく、未使用変数や潜在的なバグを検出します。
ルールは細かく設定可能で、プロジェクトの要件に合わせて調整します。

// eslint: .eslintrc.js の設定例
module.exports = {
  rules: {
    'no-unused-vars': 'error',
    'semi': ['error', 'always']
  }
};

prettier は、コードの見た目を統一するフォーマッターです。

コードの「正しさ」よりも「一貫性」を重視します。
設定項目を極力排除し、意見の対立を防ぐ設計です。

// prettier: .prettierrc の設定例
module.exports = {
  semi: true,
  singleQuote: true,
  tabWidth: 2
};

standard は、ESLint をエンジンとして使う「意見の強いスタイルガイド」です。

設定ファイルを作らず、すぐに使い始められることを目指します。
「設定なし」がデフォルトですが、必要最小限のカスタマイズは可能です。

// standard: package.json の設定例
{
  "standard": {
    "globals": [ "describe", "it" ]
  }
}

js-beautify は、伝統的なコード整形ツールです。

フォーマットに特化しており、リンティング機能は持ちません。
設定項目が多く、細かな制御が可能ですが、維持コストがかかります。

// js-beautify: .jsbeautifyrc の設定例
{
  "indent_size": 2,
  "indent_char": " ",
  "eol": "\n"
}

⚙️ 設定とカスタマイズの柔軟性

プロジェクトの規模やチームの成熟度によって、設定の柔軟性は重要な選定基準になります。

eslint は最も柔軟性が高いです。

数千ものルールから選択でき、プラグインで機能を拡張できます。
複雑なロジックを含むルールも作成可能です。

// eslint: カスタムルールの定義
module.exports = {
  rules: {
    'my-custom-rule': {
      create: function(context) {
        return {
          Identifier: function(node) {
            // カスタムロジック
          }
        };
      }
    }
  }
};

prettier は意図的に柔軟性を制限しています。

議論の余地があるオプション（セミコロンの有無など）は提供されますが、細かな制御はできません。
これにより、チーム間での設定のぶれを防ぎます。

# prettier: CLI でのオーバーライド
npx prettier --write --tab-width 4 src/

standard はカスタマイズを最小限に抑えています。

基本的には設定ファイルを作りませんが、ESLint 構成ファイルを使うことで拡張できます。
「標準に従う」ことが前提となるため、独自のルールを追加するハードルは ESLint より高いです。

// standard: ESLint config を利用した拡張
// .eslintrc.json
{
  "extends": ["standard"],
  "rules": {
    "no-console": "off"
  }
}

js-beautify は細かな設定が可能ですが、管理が大変です。

多くのオプションが存在し、チーム間で設定を同期させる必要があります。
設定ファイルがプロジェクトに散在しやすい傾向があります。

// js-beautify: 詳細な CLI オプション
js-beautify --indent-size 2 --spaces-for-tab true file.js

🐛 エラー検出とコード品質

コードのバグを未然に防ぐ能力は、リンターの重要な役割です。

eslint はエラー検出に最も優れています。

未定義変数、型に関する警告、セキュリティリスクなどを検出できます。
TypeScript と連携することで、型チェックも強化できます。

// eslint: 型チェックとの連携例
// .eslintrc.js
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  rules: {
    '@typescript-eslint/no-explicit-any': 'warn'
  }
};

prettier はエラー検出機能を持ちません。

コードを整形するだけで、ロジックの誤りは指摘しません。
ESLint と併用するのが一般的です。

// prettier: エラー検出なし
// 以下のコードも整形されるだけでエラーにはならない
const x = undefinedVariable;

standard は ESLint ベースなので、エラー検出能力があります。

デフォルトのルールセットで、一般的なバグやアンチパターンを検出します。
追加のプラグインをインストールすることで機能を強化できます。

// standard: プラグインによる拡張
npm install eslint-plugin-react
// .eslintrc.json
{
  "extends": ["standard", "plugin:react/recommended"]
}

js-beautify はエラー検出機能を持ちません。

純粋な整形ツールであり、コードの意味内容は分析しません。
構文エラーがあるコードでも、整形を試みることがあります。

// js-beautify: 構文エラーがあっても実行される
// const x = ;  <- これも整形対象となる

🔄 ワークフロー統合と自動化

開発体験（DX）を向上させるには、エディタや CI/CD パイプラインとの統合が不可欠です。

eslint は幅広いエディタサポートがあります。

VS Code、WebStorm などでリアルタイムにエラーを表示できます。
eslint --fix で一部のスタイル問題も自動修正可能です。

# eslint: 自動修正実行
npx eslint src/ --fix

prettier はエディタ統合が非常にスムーズです。

「保存時にフォーマット」機能が標準的にサポートされています。
Git フック（lint-staged）との相性が良く、コミット前に整形を強制できます。

// prettier: lint-staged 設定例
// package.json
{
  "lint-staged": {
    "*.{js,jsx}": ["prettier --write"]
  }
}

standard も ESLint ベースのため、同様の統合が可能です。

standard --fix で自動修正が行えます。
設定が少ない分、導入が早く、オンボーディングコストが低いです。

# standard: 自動修正実行
npx standard --fix

js-beautify はエディタプラグインが存在しますが、近年は減少傾向です。

主に CLI ツールとして使用されることが多いです。
モダンなワークフロー（保存時フォーマットなど）への対応は Prettier に劣ります。

# js-beautify: CLI 実行
js-beautify file.js -r

🌐 サポート範囲とエコシステム

対応言語やフレームワークの広さも選定基準になります。

eslint は JavaScript/TypeScript エコシステムの中心です。

React、Vue、Angular など、主要フレームワーク向けプラグインが充実しています。
カスタムパーサーを使用することで、Vue SFC や GraphQL なども処理可能です。

// eslint: Vue ファイルの処理
// .eslintrc.js
module.exports = {
  extends: ['plugin:vue/vue3-recommended'],
  parserOptions: {
    parser: 'vue-eslint-parser'
  }
};

prettier は多言語フォーマッターとして進化しています。

JavaScript だけでなく、CSS、HTML、Markdown、YAML なども整形できます。
単一ツールでフロントエンド資産のほとんどをカバー可能です。

// prettier: 複数ファイルの整形
npx prettier --write "src/**/*.{js,css,md}"

standard は JavaScript/Node.js に特化しています。

フレームワーク固有のルールはプラグインで追加する必要があります。
Node.js プロジェクトとの親和性が高いです。

// standard: Node.js 環境設定
// package.json
{
  "standard": {
    "env": ["node"]
  }
}

js-beautify は Web 標準言語（HTML/CSS/JS）を広くサポートします。

歴史が長いため、レガシーな構文や特殊なケースに対応していることがあります。
しかし、モダンなフレームワーク固有の構文には対応しきれない場合があります。

// js-beautify: HTML 整形
js-beautify index.html -r

📊 比較サマリー

機能	`eslint`	`prettier`	`standard`	`js-beautify`
主な目的	リンティング（品質）	フォーマット（見た目）	スタイルガイド（統合）	フォーマット（見た目）
設定の柔軟性	⭐⭐⭐⭐⭐ (最高)	⭐⭐ (制限あり)	⭐ (最小限)	⭐⭐⭐⭐ (詳細)
エラー検出	✅ 可能	❌ 不可	✅ 可能 (ESLint ベース)	❌ 不可
自動修正	✅ 一部可能	✅ 全面可能	✅ 一部可能	✅ 全面可能
多言語対応	⚠️ プラグイン依存	✅ 広範囲対応	⚠️ JS 中心	✅ Web 標準
学習コスト	高い	低い	非常に低い	中程度

💡 結論と推奨構成

現代のフロントエンド開発において、これら 4 つのツールは排他的な選択ではなく、補完的な関係にあります。

推奨される構成：eslint + prettier 最も一般的で強力な構成は、eslint でコードの品質とロジックをチェックし、prettier でコードの見た目を統一する方法です。eslint-config-prettier を使用することで、両者のルール競合を防ぎ、スムーズに連携できます。

// eslint: Prettier との連携設定
// .eslintrc.js
module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:prettier/recommended' // Prettier を ESLint ルールとして実行
  ]
};

standard の活用 小規模なプロジェクトや、設定管理に時間をかけたくないチームには standard が有効です。特に OSS プロジェクトや、新規立ち上げのスピードが求められる場合に適しています。

js-beautify の位置づけ 新しいプロジェクトで js-beautify を採用する理由はほぼありません。既存のレガシーシステムや、Prettier が対応していない特殊なファイル形式を扱う場合に限定して検討すべきツールです。

最終的な判断基準

バグ防止と品質管理が最優先 → eslint（必須）
コードスタイルの議論をなくしたい → prettier（必須）
設定ゼロで始めたい → standard
レガシー環境の維持 → js-beautify

これらを適切に組み合わせることで、メンテナンス性が高く、チーム全員が快適に開発できる環境を構築できます。

選び方: eslint vs js-beautify vs prettier vs standard

eslint:
バグの早期発見や、プロジェクト固有の複雑なコーディングルールを適用したい場合に選択します。プラグイン生態系が豊富で、TypeScript や React などのフレームワーク固有のルールも細かく制御可能です。フォーマット機能もありますが、主に品質チェック用として使います。
js-beautify:
レガシープロジェクトの維持や、Prettier がサポートしていない特定のファイル形式（HTML/CSS の古い記法など）を整形する必要がある場合に検討します。新しいプロジェクトでは、よりモダンな Prettier の使用が推奨されます。
prettier:
コードスタイルの議論を排除し、チーム全体で統一されたフォーマットを自動的に適用したい場合に最適です。設定ファイルをほとんど必要とせず、保存時に自動整形するワークフローとの相性が抜群です。
standard:
設定ファイルを管理する手間を省き、コミュニティで合意された標準的なスタイルガイドに即座に従いたい場合に選択します。ESLint ベースであるため、必要な場合はカスタマイズも可能ですが、基本は「設定なし」を前提としています。

eslintと類似したnpmパッケージ

eslintは、JavaScriptやTypeScriptのコード品質とスタイルを保つための静的コード解析ツールです。開発者はESLintを使用して、コードのエラーや潜在的な問題を特定し、コーディングスタイルを統一することができます。ESLintは非常に柔軟で拡張性が高く、さまざまなプラグインやルールを追加することで、プロジェクトのニーズに合わせた設定が可能です。しかし、ESLint以外にも、同様の目的を持つツールがいくつか存在します。以下にいくつかの代替ツールを紹介します。

prettierは、コードフォーマッターであり、特にJavaScriptやTypeScriptのコードを自動的に整形するために使用されます。Prettierは、コードのスタイルを一貫して保つことに特化しており、開発者が手動でスタイルを調整する手間を省きます。ESLintと併用することで、コードの品質とスタイルを同時に管理することができます。
stylelintは、CSSやSCSSなどのスタイルシートのための静的コード解析ツールです。スタイルの一貫性を保つためのルールを設定し、問題を特定することができます。Web開発において、CSSの品質を確保するためにStylelintを使用することは非常に有益です。ESLintと同様に、Stylelintもプラグインを通じて拡張可能です。
tslintは、TypeScriptのための静的コード解析ツールでしたが、現在はESLintに統合されつつあります。TypeScriptのプロジェクトでは、ESLintを使用することで、TypeScriptのコード品質を確保することが推奨されています。TSLintは過去のツールとして位置づけられていますが、TypeScriptのプロジェクトでの使用を考える際には、ESLintを選択することが一般的です。

これらのツールの比較については、こちらをチェックしてください: Comparing eslint vs prettier vs stylelint vs tslint。

js-beautifyと類似したnpmパッケージ

js-beautifyは、JavaScript、HTML、CSSなどのコードを美しく整形するためのライブラリです。このパッケージは、コードの可読性を向上させるために、インデントや改行を適切に配置し、全体のフォーマットを整えることができます。特に、既存のコードベースをクリーンアップしたり、他の開発者と協力する際に役立ちます。

一方で、他にも同様の機能を提供するライブラリがあります。その中の一つがprettierです。Prettierは、コードのフォーマットを自動化するための人気のあるツールで、特にJavaScriptやTypeScriptのプロジェクトで広く使用されています。Prettierは、設定が少なく、プロジェクト全体で一貫したスタイルを維持するのに役立ちます。特に、チームでの開発において、コードスタイルの不一致を避けるために非常に有用です。

js-beautifyとprettierの比較については、以下のリンクを参照してください：js-beautify vs prettierの比較。

prettierと類似したnpmパッケージ

prettierは、コードのフォーマッティングを自動化するための人気のあるツールです。JavaScript、TypeScript、HTML、CSSなど、さまざまなプログラミング言語に対応しており、コードの一貫性を保つために使用されます。Prettierを使用することで、開発者はコードスタイルに関する議論を避け、より生産的な作業に集中できるようになります。しかし、Prettierにはいくつかの代替手段もあります。以下にいくつかの選択肢を紹介します。

eslintは、JavaScriptおよびTypeScriptのための静的コード解析ツールです。主にコードの品質を向上させるために使用され、エラーや潜在的な問題を検出します。ESLintは、コードスタイルのルールを設定することもでき、Prettierと組み合わせて使用することが一般的です。ESLintは、コードの整形だけでなく、品質管理にも役立つため、より包括的なソリューションを提供します。
js-beautifyは、JavaScript、HTML、CSSのコードを整形するためのツールです。Prettierと同様に、コードを読みやすくするために使用されますが、設定やオプションが豊富で、より細かい制御が可能です。js-beautifyは、特定のスタイルガイドに従いたい場合や、カスタマイズ性を重視する場合に適しています。
standardは、JavaScriptのためのスタイルガイドであり、Lintingとフォーマッティングを組み合わせたシンプルなソリューションです。Standardは、特定の設定を必要とせず、デフォルトのスタイルに従うことで、開発者が迅速にプロジェクトを開始できるように設計されています。特に、設定を最小限に抑えたい開発者にとって便利です。

これらのパッケージの比較については、こちらをご覧ください: Comparing eslint vs js-beautify vs prettier vs standard.

standardと類似したnpmパッケージ

standardは、JavaScriptのコードスタイルと品質を保つためのスタイルガイドであり、Lintingツールです。このパッケージは、特に設定なしで使えることを目的としており、開発者が一貫したコードスタイルを維持するのを助けます。標準的なルールに従うことで、コードの可読性と保守性が向上しますが、他にもいくつかの代替ツールがあります。

eslintは、JavaScriptおよびJSXのための非常に人気のあるLintingツールです。ESLintは、開発者が独自のルールを設定できる柔軟性を提供し、コードの品質を向上させるための強力な機能を持っています。特に大規模なプロジェクトやチームでの開発において、ESLintはカスタマイズ可能なルールセットを提供するため、非常に役立ちます。
prettierは、コードフォーマッターであり、コードのスタイルを自動的に整形することに特化しています。Prettierは、コードの可読性を向上させるために、開発者が気にするべきスタイルの詳細を排除し、一定のスタイルでコードをフォーマットします。ESLintと組み合わせて使用することで、コードの品質とスタイルの両方を管理できます。
semistandardは、Standard JSに基づいたLintingツールで、いくつかのカスタマイズを加えたものです。Semistandardは、Standardのルールをベースにしつつ、セミコロンを許可するスタイルを採用しています。これにより、Standardのシンプルさを保ちながらも、セミコロンを使用したい開発者にとっての柔軟性を提供します。
xoは、ESLintをベースにしたLintingツールで、デフォルトで一貫したスタイルを提供します。XOは、設定が簡単で、開発者がすぐに使い始めることができるように設計されています。また、TypeScriptやES6+のサポートも提供しており、モダンなJavaScript開発に適しています。

これらのツールの比較については、以下のリンクを参照してください: Comparing eslint vs prettier vs semistandard vs standard vs xo。

eslint

js-beautify

prettier

standard

eslint のREADME

ESLint

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. In many ways, it is similar to JSLint and JSHint with a few exceptions:

ESLint uses Espree for JavaScript parsing.
ESLint uses an AST to evaluate patterns in code.
ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.

Installation and Usage

Prerequisites

To use ESLint, you must have Node.js (^20.19.0, ^22.13.0, or >=24) installed and built with SSL support. (If you are using an official Node.js distribution, SSL is always built in.)

If you use ESLint's TypeScript type definitions, TypeScript 5.3 or later is required.

npm Installation

You can install and configure ESLint using this command:

npm init @eslint/config@latest

After that, you can run ESLint on any file or directory like this:

npx eslint yourfile.js

pnpm Installation

To use ESLint with pnpm, we recommend setting up a .npmrc file with at least the following settings:

auto-install-peers=true
node-linker=hoisted

This ensures that pnpm installs dependencies in a way that is more compatible with npm and is less likely to produce errors.

Configuration

You can configure rules in your eslint.config.js files as in this example:

import { defineConfig } from "eslint/config";

export default defineConfig([
	{
		files: ["**/*.js", "**/*.cjs", "**/*.mjs"],
		rules: {
			"prefer-const": "warn",
			"no-constant-binary-expression": "error",
		},
	},
]);

The names "prefer-const" and "no-constant-binary-expression" are the names of rules in ESLint. The first value is the error level of the rule and can be one of these values:

"off" or 0 - turn the rule off
"warn" or 1 - turn the rule on as a warning (doesn't affect exit code)
"error" or 2 - turn the rule on as an error (exit code will be 1)

The three error levels allow you fine-grained control over how ESLint applies rules (for more configuration options and details, see the configuration docs).

Version Support

The ESLint team provides ongoing support for the current version and six months of limited support for the previous version. Limited support includes critical bug fixes, security issues, and compatibility issues only.

ESLint offers commercial support for both current and previous versions through our partners, Tidelift and HeroDevs.

See Version Support for more details.

Code of Conduct

ESLint adheres to the OpenJS Foundation Code of Conduct.

Filing Issues

Before filing an issue, please be sure to read the guidelines for what you're reporting:

Frequently Asked Questions

Does ESLint support JSX?

Yes, ESLint natively supports parsing JSX syntax (this must be enabled in configuration). Please note that supporting JSX syntax is not the same as supporting React. React applies specific semantics to JSX syntax that ESLint doesn't recognize. We recommend using eslint-plugin-react if you are using React and want React semantics.

Does Prettier replace ESLint?

No, ESLint and Prettier have different jobs: ESLint is a linter (looking for problematic patterns) and Prettier is a code formatter. Using both tools is common, refer to Prettier's documentation to learn how to configure them to work well with each other.

What ECMAScript versions does ESLint support?

ESLint has full support for ECMAScript 3, 5, and every year from 2015 up until the most recent stage 4 specification (the default). You can set your desired ECMAScript syntax and other settings (like global variables) through configuration.

What about experimental features?

ESLint's parser only officially supports the latest final ECMAScript standard. We will make changes to core rules in order to avoid crashes on stage 3 ECMAScript syntax proposals (as long as they are implemented using the correct experimental ESTree syntax). We may make changes to core rules to better work with language extensions (such as JSX, Flow, and TypeScript) on a case-by-case basis.

In other cases (including if rules need to warn on more or fewer cases due to new syntax, rather than just not crashing), we recommend you use other parsers and/or rule plugins. If you are using Babel, you can use @babel/eslint-parser and @babel/eslint-plugin to use any option available in Babel.

Once a language feature has been adopted into the ECMAScript standard (stage 4 according to the TC39 process), we will accept issues and pull requests related to the new feature, subject to our contributing guidelines. Until then, please use the appropriate parser and plugin(s) for your experimental feature.

Which Node.js versions does ESLint support?

ESLint updates the supported Node.js versions with each major release of ESLint. At that time, ESLint's supported Node.js versions are updated to be:

The most recent maintenance release of Node.js
The lowest minor version of the Node.js LTS release that includes the features the ESLint team wants to use.
The Node.js Current release

ESLint is also expected to work with Node.js versions released after the Node.js Current release.

Refer to the Quick Start Guide for the officially supported Node.js versions for a given ESLint release.

Where to ask for help?

Open a discussion or stop by our Discord server.

Why doesn't ESLint lock dependency versions?

Lock files like package-lock.json are helpful for deployed applications. They ensure that dependencies are consistent between environments and across deployments.

Packages like eslint that get published to the npm registry do not include lock files. npm install eslint as a user will respect version constraints in ESLint's package.json. ESLint and its dependencies will be included in the user's lock file if one exists, but ESLint's own lock file would not be used.

We intentionally don't lock dependency versions so that we have the latest compatible dependency versions in development and CI that our users get when installing ESLint in a project.

The Twilio blog has a deeper dive to learn more.

Releases

We have scheduled releases every two weeks on Friday or Saturday. You can follow a release issue for updates about the scheduling of any particular release.

Security Policy

ESLint takes security seriously. We work hard to ensure that ESLint is safe for everyone and that security issues are addressed quickly and responsibly. Read the full security policy.

Semantic Versioning Policy

ESLint follows semantic versioning. However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy for ESLint:

Patch release (intended to not break your lint build)
- A bug fix in a rule that results in ESLint reporting fewer linting errors.
- A bug fix to the CLI or core (including formatters).
- Improvements to documentation.
- Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
- Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
Minor release (might break your lint build)
- A bug fix in a rule that results in ESLint reporting more linting errors.
- A new rule is created.
- A new option to an existing rule that does not result in ESLint reporting more linting errors by default.
- A new addition to an existing rule to support a newly-added language feature (within the last 12 months) that will result in ESLint reporting more linting errors by default.
- An existing rule is deprecated.
- A new CLI capability is created.
- New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
- A new formatter is created.
- eslint:recommended is updated and will result in strictly fewer linting errors (e.g., rule removals).
Major release (likely to break your lint build)
- eslint:recommended is updated and may result in new linting errors (e.g., rule additions, most rule option updates).
- A new option to an existing rule that results in ESLint reporting more linting errors by default.
- An existing formatter is removed.
- Part of the public API is removed or changed in an incompatible way. The public API includes:
  - Rule schemas
  - Configuration schema
  - Command-line options
  - Node.js API
  - Rule, formatter, parser, plugin APIs

According to our policy, any minor update may report more linting errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (~) in package.json e.g. "eslint": "~3.1.0" to guarantee the results of your builds.

ESM Dependencies

Since ESLint is a CommonJS package, there are restrictions on which ESM-only packages can be used as dependencies.

Packages that are controlled by the ESLint team and have no external dependencies can be safely loaded synchronously using require(esm) and therefore used in any contexts.

For external packages, we don't use require(esm) because a package could add a top-level await and thus break ESLint. We can use an external ESM-only package only in case it is needed only in asynchronous code, in which case it can be loaded using dynamic import().

These policies don't apply to packages intended for our own usage only, such as eslint-config-eslint.

License

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.