# Install standard with Homebrew

JavaScript Style Guide, with linter & automatic code fixer. Version 17.1.2 via Homebrew; verified from local package data.

## Install

```sh
sudo av install brew:standard
```

Additional install commands:

### macOS

- Homebrew (100%):

```sh
brew install standard
```

  Evidence: local Homebrew formula metadata

## Package facts

- **Package key:** brew:standard
- **Package manager:** Homebrew
- **Version:** 17.1.2
- **Source summary:** JavaScript Style Guide, with linter & automatic code fixer
- **Homepage:** <https://standardjs.com/>
- **Repository:** <https://github.com/standard/standard>
- **Generated:** 2026-08-03T19:37:03+00:00

## Executables

- standard (alias)

## Install behavior

- Bottle: not available

## Freshness

- Page generated: 2026-08-03
- Package-manager version: 17.1.2
## Project history and usage

StandardJS, distributed by the `standard` CLI, packages a JavaScript style guide together with linting and automatic fixing. Its appeal in CLI and package-manager culture is that a project can install one package and run one command instead of maintaining a separate ESLint configuration.

### Project history

The project presents itself as a JavaScript style guide, linter, and formatter. Its own changelog records version 4.0.0 in May 2015, and later major releases track the underlying ESLint ecosystem, including the 2022 `standard` 17 release built around ESLint 8 compatibility.

### Adoption history

Adoption grew around the promise of no `.eslintrc` files and a repeatable `standard` command. The README explicitly encourages adding `standard` to `package.json` and wiring it into `npm test`, which made it fit the everyday workflow of npm packages, CI, and pull-request review.

### How it is used

Typical use is installing `standard` globally or as a development dependency, then running `standard`, `npx standard`, or `standard --fix`. Configuration, when needed, is stored under the `standard` key in `package.json` rather than in a separate dotfile.

### Why package nerds care

Package maintainers care about StandardJS because it made style enforcement feel like a dependency choice rather than a configuration project. It also demonstrates the tradeoff package ecosystems often debate: convention and speed over local bikeshedding.

### Timeline

- 2015: Changelog records StandardJS 4.0.0.
- 2016: Version 8.0.0 adds the built-in `--fix` workflow.
- 2022: Version 17 aligns StandardJS with ESLint 8.

### Related projects

- StandardJS is built around ESLint-related packages such as `eslint-config-standard`, `eslint-config-standard-jsx`, `standard-engine`, and ESLint plugins for import, promise, React, and Node rules.

### Sources

- <https://github.com/standard/standard README: describes the tool as a JavaScript style guide, linter, and formatter with no configuration and `standard --fix`.>
- <https://github.com/standard/standard/blob/master/CHANGELOG.md: records releases including 4.0.0, 8.0.0, and 17.0.0.>
- <https://github.com/standard/standard/blob/master/package.json: lists the official repository, homepage, dependencies, and keywords.>


## Security Notes

narrow executable package without higher-risk signals.

- **Geiger risk:** green / low
- narrow executable package without higher-risk signals


## Configuration and credential file locations

These source-backed paths show where this package keeps local settings or durable credentials. Automic Vault can use them as review targets for secret scanning, migration, and command approval.


## Configuration files

- Unix: package.json

## Combined YAML source

View the package source record on GitHub. [combined/standard.yml](https://github.com/mxcl/pkgdb/blob/main/combined/standard.yml)


## Sources

- pkg.so package database
- Geiger risk classifier
- curated configuration and credential file locations
- curated package history
- pkgdb category and tag curation
- cross-ecosystem install command graph