JavaScript Standard Style

Common errors

• Expected '===' and instead saw '=='.

  cause Using the loose equality operator (==) instead of the strict equality operator (===).
  fix Change `==` to `===` or `!=` to `!==`.

• Extra semicolon.

  cause `standard` enforces a 'no semicolons' rule where they are not strictly required.
  fix Remove the unnecessary semicolon. `standard --fix` can often resolve these automatically.

• Missing space before function parentheses.

  cause Function declarations or expressions are missing a space between the function name (or keyword) and its opening parenthesis.
  fix Add a space: `function foo ()` instead of `function foo()` or `async () =>` instead of `async() =>`. `standard --fix` often corrects this.

• 'someVar' is defined but never used.

  cause A variable has been declared but its value is never read or referenced in the code.
  fix Remove the unused variable or use it. If intentional, you might need to use `// eslint-disable-line no-unused-vars` (but this goes against `standard`'s philosophy).

• 'someVar' is never reassigned. Use 'const' instead.

  cause A variable declared with `let` or `var` is not reassigned after its initial declaration.
  fix Change `let` or `var` to `const` for variables that do not change their value. `standard --fix` can automate this.

Warnings

• breaking Version 17.0.0 involved a full synchronization with ESLint 8. This included significant internal dependency updates (e.g., ESLint itself, `eslint-config-standard`, `eslint-plugin-react`), and notably, the replacement of `eslint-config-node` with `eslint-config-n`. This means previous ESLint disable comments like `// eslint-disable-line node/no-deprecated-api` must be updated to reference `n/` rules instead. The `object-shorthand` rule also changed to a warning by default, and `--verbose` output is now standard.
  Fix: Review the changelog for v17.0.0 to identify specific rule changes. Update ESLint disable comments (e.g., change `node/` to `n/`). Run `standard --fix` to automatically resolve most stylistic issues after upgrading.
• gotcha `standard` enforces a strict, opinionated style with 'zero configuration'. This means you cannot customize individual rules via a configuration file (e.g., `.eslintrc`). If you require fine-grained control over ESLint rules, you should use ESLint directly with `eslint-config-standard` as a base configuration, which defeats the purpose of using `standard` itself.
  Fix: Accept `standard`'s rules as-is. If customization is essential, migrate to direct ESLint usage and extend `eslint-config-standard` to layer your own changes, or consider `standardx` for minor tweaks.
• gotcha Using `standard` alongside other formatters like Prettier can lead to conflicts due to differing formatting rules, resulting in inconsistent code and 'formatting wars'. StandardJS has specific opinions (e.g., no semicolons, single quotes) that may clash with Prettier's defaults or other configurations.
  Fix: Choose one primary formatter/linter. If using `standard`, it's recommended to disable other formatters (e.g., Prettier) in your editor's workspace settings. If you need both, consider 'ejecting' from `standard` and using ESLint with `eslint-config-standard` and `eslint-config-prettier` to manage conflicts.
• deprecated Running `standard` on Node.js versions older than `^12.22.0 || ^14.17.0 || >=16.0.0` (as specified in `engines` field) might lead to silent failures or unexpected behavior due to the `version-guard` mechanism introduced in v17.1.0. While not an explicit error, it can prevent linting from running correctly without clear feedback.
  Fix: Ensure your Node.js environment meets the minimum requirements (`^12.22.0 || ^14.17.0 || >=16.0.0`). Upgrade Node.js if necessary.

Install

• npm install standard npm
• yarn add standard yarn
• pnpm add standard pnpm

Imports

• standard (CLI)
  wrong:

  import standard from 'standard'

  correct:

  npx standard --fix

  Standard is primarily a command-line tool. It is not designed for direct module import for its core linting/fixing functionality. Use `npx` or a globally/locally installed `standard` binary.
• lintText
  wrong:

  const standard = require('standard'); standard.lintText(...)

  correct:

  import { lintText } from 'standard'

  For programmatic use in Node.js, specifically to lint a string of code, `lintText` can be imported. Ensure you're using ESM syntax if your project is ESM-first, otherwise `require` might work for older versions/setups.
• lintFiles
  wrong:

  const standard = require('standard'); standard.lintFiles(...)

  correct:

  import { lintFiles } from 'standard'

  For programmatic use in Node.js to lint an array of file paths, `lintFiles` is available. As with `lintText`, favor ESM imports. These programmatic APIs are less commonly used than the CLI.

Quickstart

Demonstrates `standard`'s automatic fixing capabilities by showing a JavaScript file with common style violations (semicolons, var, ==, double quotes) and the command to fix them.

/* eslint-disable no-unused-vars */
const fs = require('fs')

function exampleFunc(arg1) {;
  var unusedVar = 10
  const myString = "hello world"

  if (arg1 == null) {
    console.log(myString)
  }
}

// Save this to a file like 'broken.js'
// Then run 'npx standard broken.js --fix'
// You can also add `"test": "standard"` to your package.json scripts and run `npm test`