xo vs eslint vs semistandard vs standard
JavaScript 代碼風格和靜態分析工具
xoeslintsemistandardstandard類似套件:

JavaScript 代碼風格和靜態分析工具

這些工具是用於 JavaScript 代碼的靜態分析和風格檢查,幫助開發者保持代碼的一致性和可讀性。它們提供了一套規則來檢查代碼,並在發現問題時提供反饋。這不僅有助於減少錯誤,還能提高團隊協作的效率,因為所有開發者都遵循相同的代碼風格。這些工具各有特點,適合不同的開發需求和團隊文化。

npm下載趨勢

3 年

GitHub Stars 排名

統計詳情

套件
下載數
Stars
大小
Issues
發布時間
許可
xo165,0857,99496.2 kB32 個月前MIT
eslint027,6052.95 MB1394 天前MIT
semistandard01,40847.6 kB03 年前MIT
standard029,426164 kB1282 年前MIT

功能比較: xo vs eslint vs semistandard vs standard

配置靈活性

  • xo:

    XO 結合了 ESLint 的靈活性,並提供了一些預設的規則和最佳實踐。它也支持自動修復功能,讓開發者可以更輕鬆地維護代碼風格。

  • eslint:

    ESLint 提供了高度的配置選項,允許開發者根據項目的需求自定義規則。你可以選擇啟用或禁用特定的規則,並且可以使用插件來擴展功能。

  • semistandard:

    Semistandard 基於 StandardJS,提供了一個簡化的配置選項,允許少量自定義。這使得它適合希望快速上手但又有一些靈活性需求的開發者。

  • standard:

    Standard 是一個無配置的工具,強制執行一組預設的代碼風格規則。這意味著開發者不需要花時間去配置,適合希望快速開始的項目。

社區支持

  • xo:

    XO 擁有一個活躍的社區,並且與 ESLint 兼容,這使得它能夠利用 ESLint 的生態系統。

  • eslint:

    ESLint 擁有一個龐大的社區和豐富的插件生態系統,這使得它成為最受歡迎的靜態代碼檢查工具之一。你可以找到大量的資源和支持,幫助你解決問題。

  • semistandard:

    Semistandard 的社區相對較小,但仍然有一些支持和資源可用。它的簡單性使得新手能夠快速上手。

  • standard:

    Standard 的社區也相對較小,但它的無配置特性使得使用者能夠快速上手,並且有一些基本的支持。

學習曲線

  • xo:

    XO 的學習曲線也相對平緩,因為它提供了預設的規則和現代的開發體驗。對於熟悉 ESLint 的開發者來說,上手非常快。

  • eslint:

    由於其高度的可配置性,ESLint 的學習曲線可能較陡峭,特別是對於初學者來說。理解所有的規則和配置選項可能需要一些時間。

  • semistandard:

    Semistandard 的學習曲線相對較平緩,因為它基於 StandardJS,並且提供了簡化的配置。適合新手和小型項目。

  • standard:

    Standard 的學習曲線非常平緩,因為它無需配置,開發者可以直接使用預設的規則。這使得它成為初學者的理想選擇。

自動修復功能

  • xo:

    XO 提供了自動修復功能,並且可以幫助開發者快速解決代碼中的問題,這對於提高開發效率非常有幫助。

  • eslint:

    ESLint 支持自動修復功能,開發者可以通過簡單的命令修復一些常見的代碼問題,這對於提高開發效率非常有幫助。

  • semistandard:

    Semistandard 也支持自動修復功能,但由於其簡化的規則集,修復的範圍可能不如 ESLint 廣泛。

  • standard:

    Standard 不支持自動修復功能,這意味著開發者需要手動修復代碼問題。

代碼風格一致性

  • xo:

    XO 提供了一組現代的預設規則,幫助團隊保持代碼風格的一致性,並且支持自動修復功能。

  • eslint:

    ESLint 允許開發者根據項目的需求自定義規則,這可能導致不同團隊之間的代碼風格不一致。

  • semistandard:

    Semistandard 提供了一個簡化的規則集,幫助團隊保持代碼風格的一致性,特別是在小型項目中。

  • standard:

    Standard 強制執行一組預設的代碼風格規則,這確保了團隊之間的代碼風格一致性,適合希望快速上手的開發者。

如何選擇: xo vs eslint vs semistandard vs standard

  • xo:

    選擇 XO 如果你希望結合 ESLint 的靈活性與更現代的開發體驗。XO 預設使用 ES2015+ 語法,並且提供了許多開箱即用的功能,如自動修復和更好的錯誤報告。

  • eslint:

    選擇 ESLint 如果你需要高度可配置的靜態代碼檢查工具,並且希望能夠自定義規則集以滿足特定需求。ESLint 擁有強大的社區支持和插件生態系統,適合大型項目和多樣化的開發環境。

  • semistandard:

    選擇 Semistandard 如果你想要一個簡單的解決方案,並且希望遵循 StandardJS 的風格,但又希望能夠進行一些自定義。它提供了一個簡化的配置,適合小型項目或初學者。

  • standard:

    選擇 Standard 如果你希望使用一個無需配置的代碼風格工具,並且想要強制執行一致的代碼風格。Standard 提供了一組預設的規則,適合希望快速上手的開發者。

xo 的 README


XO


JavaScript/TypeScript linter (ESLint wrapper) with great defaults

Coverage Status XO code style

Opinionated but configurable ESLint wrapper with lots of goodies included. Enforces strict and readable code. Never discuss code style on a pull request again! No decision-making. No eslint.config.js to manage. It just works!

It uses ESLint underneath, so issues regarding built-in rules should be opened over there.

XO requires your project to be ESM.

Highlights

Install

npm install xo --save-dev

You must install XO locally. You can run it directly with $ npx xo.

For framework-specific linting, see Astro, React, Svelte, and Vue.

Usage

$ xo --help

	Usage
		$ xo [<file|glob> ...]

	Options
		--fix                     Automagically fix issues
		--fix-dry-run             Automagically fix issues without saving the changes to the file system
		--reporter                Reporter to use
		--space                   Use space indent instead of tabs [Default: 2]
		--config                  Path to a XO configuration file
		--semicolon               Use semicolons [Default: true]
		--prettier                Format with prettier or turn off Prettier-conflicted rules when set to 'compat' [Default: false]
		--print-config            Print the effective ESLint config for the given file
		--version                 Print XO version
		--open                    Open files with issues in your editor
		--quiet                   Show only errors and no warnings
		--max-warnings            Number of warnings to trigger nonzero exit code [Default: -1]
		--stdin                   Validate/fix code from stdin
		--stdin-filename          Specify a filename for the --stdin option
		--ignore                  Ignore pattern globs, can be set multiple times
		--suppressions-location   Path to a custom ESLint suppressions file
		--cwd=<dir>               Working directory for files [Default: process.cwd()]

	Examples
		$ xo
		$ xo index.js
		$ xo *.js !foo.js
		$ xo --space
		$ xo --print-config=index.js
		$ echo 'const x=true' | xo --stdin --fix

	Tips
		- Add XO to your project with `npm init xo`.
		- Put options in xo.config.js instead of using flags so other tools can read it.

Default code style

Any of these can be overridden if necessary.

  • Tab indentation (or space)
  • Semicolons (or not)
  • Single-quotes
  • Trailing comma for multiline statements
  • No unused variables
  • Space after keyword if (condition) {}
  • Always === instead of ==

Check out an example and the ESLint rules.

Workflow

The recommended workflow is to add XO locally to your project and run it with the tests.

Simply run $ npm init xo (with any options) to add XO to create an xo.config.js.

Config

You can configure XO options by creating an xo.config.js or an xo.config.ts file in the root directory of your project, or you can add an xo field to your package.json. XO supports all js/ts file extensions (js,jsx,mjs,cjs,ts,tsx,mts,cts), popular framework extensions (vue,svelte,astro), HTML, Markdown, JSON, and CSS automatically. A XO config is an extension of ESLint's Flat Config. Like ESLint, an XO config exports an array of XO config objects. XO config objects extend ESLint Configuration Objects. This means all the available configuration params for ESLint also work for XO. However, XO enhances and adds extra params to the configuration objects to make them easier to work with.

Config types

XO exports the types FlatXoConfig, XoConfigItem, and other types for you to get TypeScript validation on your config files.

examples: xo.config.js

/** @type {import('xo').FlatXoConfig} */
const xoConfig = [...]

xo.config.ts

import {type FlatXoConfig} from 'xo';

const xoConfig: FlatXoConfig = [...]
export default [...] satisfies import('xo').FlatXoConfig

files

Type: string | (string | string[])[]
Default: **/*.{js,jsx,mjs,cjs,ts,tsx,mts,cts,vue,svelte,astro}

A glob string, array of globs, or ESLint's native format (where nested arrays create AND patterns) indicating which files the config object applies to. By default XO will apply the configuration to all JavaScript, TypeScript, and framework files. To configure other file types, such as HTML, Markdown, JSON, or CSS, set files explicitly. This is compatible with ESLint plugin configs, so you can spread them directly into your XO config.

Tip: If you are adding additional @typescript-eslint rules to your config, these rules will apply to JS files as well unless you separate them appropriately with the files option. @typescript-eslint rules set to 'off' or 0, however, will have no effect on JS linting.

ignores

Type: string | string[]

Some paths are ignored by default, including lockfiles and paths in .gitignore. Additional ignores can be added here.

Tip: For global ignores, keep ignores as the only key in the config item. You can optionally set a name property. Adding more properties will cause ignores to be scoped down to your files selection, which may have unexpected effects.

Global negated ignores are supported in both config files and the CLI for reopening XO's built-in ignored paths. This includes directory globs like !dist/**, file globs like !**/*.min.js, and literal file paths like !dist/src/index.js.

When global ignores are involved, XO uses them in this order:

  1. Built-in default ignores
  2. Global config ignores
  3. CLI ignores

XO keeps positive ignores for fast file discovery and only rechecks XO's own default-ignored paths. ESLint makes the final ignore decision.

space

Type: boolean | number
Default: false (tab indentation)

Set it to true to get 2-space indentation or specify the number of spaces.

Global only. For file-specific indentation, use the @stylistic/indent and @html-eslint/indent rules.

This option exists for pragmatic reasons, but I would strongly recommend you read “Why tabs are superior”.

semicolon

Type: boolean
Default: true (Semicolons required)

Set it to false to enforce no-semicolon style.

Global only. For file-specific semicolon rules, use the @stylistic/semi rule.

prettier

Type: boolean | 'compat'
Default: false

Format code with Prettier.

Global only. For file-specific Prettier overrides, configure the prettier/prettier rule.

XO applies its own Prettier options:

Any options you set in a Prettier config still apply for anything XO does not configure (like printWidth or plugins), but XO's own style settings take precedence.

Compat

If the Prettier option is set to compat, instead of formatting your code automatically, XO will turn off all rules that conflict with Prettier code style and allow you to pass your formatting to the Prettier tool directly.

Astro

To lint Astro files, install eslint-plugin-astro:

npm install --save-dev eslint-plugin-astro

Then spread its recommended config in your xo.config.js:

import astroPlugin from 'eslint-plugin-astro';

const xoConfig = [
	...astroPlugin.configs.recommended,
];

export default xoConfig;

React

To lint React files, install eslint-config-xo-react:

npm install --save-dev eslint-config-xo-react

Then spread it in your xo.config.js:

import xoReact from 'eslint-config-xo-react';

const xoConfig = [
	...xoReact(),
];

export default xoConfig;

[!NOTE] Until eslint-plugin-react supports ESLint 10 natively, you may need to wrap the config with fixupConfigRules from @eslint/compat.

Svelte

To lint Svelte files, install eslint-plugin-svelte:

npm install --save-dev eslint-plugin-svelte

Then spread its recommended config in your xo.config.js:

import sveltePlugin from 'eslint-plugin-svelte';

const xoConfig = [
	...sveltePlugin.configs.recommended,
];

export default xoConfig;

Vue

To lint Vue files, install eslint-plugin-vue:

npm install --save-dev eslint-plugin-vue

Then spread its recommended config in your xo.config.js:

import vuePlugin from 'eslint-plugin-vue';

const xoConfig = [
	...vuePlugin.configs['flat/recommended'],
];

export default xoConfig;

Shareable configs

If you want to extend a shareable ESLint config or any other npm package, use xo.config.js instead of package.json, since package.json only supports serializable values and cannot import.

xo.config.js

export {default} from 'my-shareable-config';

You can also extend and override:

import myConfig from 'my-shareable-config';

export default [
	...myConfig,
	{
		rules: {
			// Your overrides
		},
	},
];

TypeScript

XO will automatically lint TypeScript files (.ts, .mts, .cts, and .tsx) with the rules defined in eslint-config-xo-typescript#use-with-xo.

XO will handle the @typescript-eslint/parser project option automatically even if you don't have a tsconfig.json in your project.

You can opt out of XO's automatic tsconfig handling by specifying your own languageOptions.parserOptions.project, languageOptions.parserOptions.projectService, or languageOptions.parserOptions.tsconfigRootDir. Files in a config with these properties will be excluded from automatic tsconfig handling.

Usage as an ESLint Configuration

There are two different ways to use XO's rules with ESLint directly, depending on whether you use the xo CLI.

Without the xo CLI

If you don't use the xo CLI and just want XO's rules in ESLint, use eslint-config-xo. It accepts the same core style options as XO, including Prettier integration:

eslint.config.js

import eslintConfigXo from 'eslint-config-xo';

export default [
	...eslintConfigXo({space: true, prettier: true}),
];

[!NOTE] This replaces the old xoToEslintConfig helper. For example, xoToEslintConfig([{space: true, prettier: true}]) becomes eslintConfigXo({space: true, prettier: true}). For per-file overrides, add normal ESLint config objects alongside it.

With the xo CLI (editor integration)

If you use the xo CLI but your editor only has the ESLint extension (not XO's), add an eslint.config.js that re-exports the adapter. It reads your xo.config.js and generates the matching ESLint config automatically, so your editor shows the same errors as running xo — without duplicating your config.

eslint.config.js

export {default} from 'xo/eslint-adapter';

Tips

Monorepo

Put a xo.config.js with your config at the root and do not add a config to any of your bundled packages.

Including files ignored by default

To include files that XO ignores by default, add them as negative globs in the ignores option:

const xoConfig = [{ignores: ['!vendor/**']}];

export default xoConfig;

This also works for narrower carve-outs:

const xoConfig = [{ignores: ['!dist/src/**', '!dist/src/index.js']}];

export default xoConfig;

Warnings are hidden when there are errors

When XO finds errors, warnings are automatically hidden to reduce noise and let you focus on what matters. Warnings are shown normally when there are no errors. Use --quiet to always suppress warnings, or --max-warnings to treat warnings as errors.

Bulk suppression

XO automatically respects an eslint-suppressions.json file if one exists in the working directory. This lets you suppress existing violations while still enforcing rules on new code — useful for incrementally adopting stricter rules in a large codebase.

To generate the suppressions file, create a temporary eslint.config.js using xo/eslint-adapter and run ESLint with --suppress-all:

npx eslint --suppress-all

Commit the resulting eslint-suppressions.json to share suppressions across your team.

To use a custom suppressions file path, pass --suppressions-location:

xo --suppressions-location config/suppressions.json

FAQ

What does XO mean?

It means hugs and kisses.

Why not Standard?

The Standard style is a really cool idea. I too wish we could have one style to rule them all! But the reality is that the JS community is just too diverse and opinionated to create one code style. They also made the mistake of pushing their own style instead of the most popular one. In contrast, XO is more pragmatic and has no aspiration of being the style. My goal with XO is to make it simple to enforce consistent code style with close to no config. XO comes with my code style preference by default, as I mainly made it for myself, but everything is configurable.

Why not ESLint?

XO is based on ESLint. This project started out as just a shareable ESLint config, but it quickly grew out of that. I wanted something even simpler. Just typing xo and be done. No decision-making. No config. I also have some exciting future plans for it. However, you can still get most of the XO benefits while using ESLint directly with the ESLint shareable config.

Editor plugins

Build-system plugins

Configs

Support

Related

Badge

Show the world you're using XO → XO code style

[![XO code style](https://shields.io/badge/code_style-5ed9c7?logo=xo&labelColor=gray&logoSize=auto)](https://github.com/xojs/xo)

Large badge: XO code style

[![XO code style](https://shields.io/badge/code_style-5ed9c7?style=for-the-badge&logo=xo&labelColor=gray&logoSize=auto)](https://github.com/xojs/xo)

Or customize the badge.

You can also find some nice dynamic XO badges on badgen.net.