# eslint-config-standard: the rule set behind JavaScript Standard Style

> A shareable ESLint configuration that holds the Standard rules in one place, with a flat config entry point and a plain warning that most people should install the standard package instead.

**standard/eslint-config-standard** — ESLint Config for JavaScript Standard Style

- Repository: https://github.com/standard/eslint-config-standard
- Website: https://standardjs.com
- Stars: 2,645 · Forks: 542
- Language: TypeScript
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/standard-eslint-config-standard

## Two install lines, and one of them is the whole story

The README is short and front-loads its own advice. It describes itself as the ESLint config of JavaScript Standard Style, then tells advanced users that they probably want the `standard` package instead, linking to standardjs.com.

The install itself is one command:

```bash
npm install --save-dev eslint eslint-config-standard
```

That tells you the peer relationship: ESLint is a peer dependency, so the host project owns the version, and this package supplies configuration. The `standard` package instead bundles a global command line program named `standard` that you can run directly or add to your `npm test` script, which is the difference between the two packages in one sentence.

If you want the style enforced and nothing else, `standard` is the shorter route. If you have an ESLint setup already and want these rules inside it, this is the package.

## Flat config entry, and an older peer dependency

The README documents a flat ESLint configuration, and the example shows the array form with an overrides slot:

```js
const standard = require('eslint-config-standard')

module.exports = [
    standard,
    {
      // your overrides here
    }
] 
```

Two details in that snippet matter more than they look. The package is consumed with `require`, so it exposes a CommonJS entry rather than being an ESM-only module. And because it returns an array, your project-specific rules go in a later object, where they take precedence over the shared config.

Here is where the package is internally inconsistent, and a reader has to hold both facts. The README presents flat config as the way to use the package, while `package.json` declares a peer dependency of `"eslint": "^8.0.1"` and pins `eslint: 8.55.0` for development. Flat config is the format ESLint 9 made the default; on ESLint 8 it exists behind a flag, and the `.eslintrc.js` file in the repository root is the legacy format. Both are true of this repository at the same time.

The practical consequence is that on a project still on ESLint 8 you may need the flat config opt-in flag, and on ESLint 9 the same package may be waiting on a peer range bump. Neither the README nor the changelog excerpt settles it, so checking the sibling repository and the release notes is the step that removes the doubt.

## What actually ships in the tarball

The `files` array in `package.json` is the honest description of the deliverable, and it is short: `CHANGELOG.md`, `LICENSE`, `README.md`, `lib/index.js` and `lib/index.d.ts`. Everything else in the repository, including tests and tooling, is not part of the published artifact.

The published entry points are declared as `main: lib/index.js` and `types: lib/index.d.ts`, which tells you the source of truth is TypeScript that gets compiled into `lib/`. The tree confirms it: `src/` and `tsconfig.json` at the top level, with no `lib/` directory checked in, because `lib/` only exists after a build. GitHub reports the repository language as TypeScript.

So the package a consumer installs is a compiled rule object with type declarations, not the `.eslintrc.js` you can see in the tree. That distinction matters if you have ever browsed a shareable config and tried to copy rules out of it by reading the repository: what you read in `src/` is what you get, and what you saw in `.eslintrc.js` is only how the project lints itself.

## The tooling around a very small package

For a configuration object with no runtime logic, the interesting part is the release and quality machinery, and it is all visible in the tree: `lefthook.yml` for git hooks, `commitlint.config.js` with `commitlint-config-standard` for conventional commit messages, `.releaserc.yml` with `semantic-release` for versioning, and `renovate.json` for dependency updates. `get-node-supported-versions.sh` exists to compute the CI matrix, and `.github/` holds the workflow the CI badge points at.

There is an `.eslintrc.js` because the project lints itself with a config, and an `.eslintignore`, an `.editorconfig` and `CHANGELOG.md`. A `bench/` directory is not present here, so the previous repository's benchmark work does not carry over.

Two dependencies in the dev list explain the rule contents: `eslint-plugin-import`, `eslint-plugin-n` and `eslint-plugin-promise`. Those plugins are where rules like no-unused-vars, import ordering and promise handling come from, so the Standard style is largely expressed as configuration of plugins rather than as core ESLint rules. `eslint-config-standard-with-typescript` appears in the dev dependencies too, which is how the project lints its own TypeScript source.

## Project health and the honest limits of the README

The repository is active and small in the way a shared config should be. It has 2,644 stars, 543 forks, 29 open issues, an MIT licence, and the last push was on 2026-09-19. A high fork count against a low issue count fits a package that people vendor into their own lint setup rather than one that generates support traffic.

The README's scope is narrow by design, and it says where the rest lives. For the full listing of rules, editor plugins and FAQs, it points at the main JavaScript Standard Style repository rather than duplicating them. The rule list is therefore not in this repository's documentation at all, which is the single most important thing to know before you decide whether to adopt it.

What you can evaluate here is narrow but real: the config format, the peer dependency range, the published files, and the fact that the style is expressed mostly through three plugins. What you have to get from the parent repository is the rule inventory itself.

## Conclusion

This package is deliberately not the friendly path. It exists for the cases where you already have ESLint installed and want Standard's rules as one entry in your own config, and the README says so in its second line by steering you to the `standard` package instead. What the repository settles is the rule set, the peer dependency on ESLint and what actually ships in the tarball. What it does not settle is why the flat config example and the ESLint 8 peer dependency are both present, which is a real question to check against the sibling repository and the release notes before you adopt it on a project pinned to the older major. Start by installing `standard` if you want the style, and reach for this package only when you need the rules inside an existing ESLint setup.

## FAQ

### What is the difference between ESLint config.js and eslintrc files?

The flat config form is the one this README documents: an `eslint.config.js` file exporting an array where this package's config is the first entry and your own overrides follow it. The `.eslintrc` format is the legacy layout, and this repository still has an `.eslintrc.js` at its root because the project lints itself that way. You can meet both in the same repository, so read which one your ESLint major expects before copying either.

### How do I configure ESLint for TypeScript?

This package is the JavaScript Standard Style rules and it carries no TypeScript-specific rules of its own, which the README indicates by directing you to the main Standard Style repository for the full rule listing. Its sibling package for TypeScript appears in this repository's development dependencies, `eslint-config-standard-with-typescript`, which is how the project's own `src/` is linted. The README also notes that a TypeScript-aware config is a separate decision from the JavaScript one.

### Do I need eslint-config-standard if I use the standard package?

No. The README tells advanced users that they probably want the `standard` package instead, which installs a global command line program called `standard` that you can run directly or add to your `npm test` script. This package is for the other case: ESLint is already installed in your project and you want the Standard rules as one entry in your own configuration.

## Sources

- [Issues](https://github.com/standard/eslint-config-standard/issues)
- [License: MIT](https://github.com/standard/eslint-config-standard/blob/master/LICENSE)
- [Project website](https://standardjs.com)
- [README](https://github.com/standard/eslint-config-standard/blob/master/README.md)
- [standard/eslint-config-standard on GitHub](https://github.com/standard/eslint-config-standard)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/standard-eslint-config-standard