A spiritual successor to the standard javascript style guide

Initial development sponsored by:

Table of Contents

• Quick Start
  • Migrate from standard
  • Add to new project
• Configuration options
• Extending
• Additional exports
  • resolveIgnoresFromGitignore()
  • Exported plugins
• Missing for 1.0.0 release
• Differences to standard / eslint-config-standard 17.x
  • Changed rules
  • Relaxed rules
  • Missing bits
• Config helper
  • Config migration
• Readme badges
• Mission statement
  • Rule guidelines
• Governance
• Used by

Quick Start

Migrate from standard

1. npm install -D neostandard eslint
2. npx neostandard --migrate > eslint.config.js (uses our config helper)
3. Replace standard with eslint in all places where you run standard, eg. "scripts" and .github/workflows/ (neostandard CLI tracked in #2)
4. (Add ESLint editor integration, eg. VS Code ESLint extension)
5. Cleanup:
   • npm uninstall standard
   • Remove unused "standard" top level key from your package.json
   • Deactivate standard specific integrations if you no longer use them (eg. vscode-standard))

Add to new project

1. npm install -D neostandard eslint

2. Add an eslint.config.js:

   Using config helper:

   npx neostandard --esm > eslint.config.js

   Or to get CommonJS:

   npx neostandard > eslint.config.js

   Or manually create the file as ESM:

   import neostandard from 'neostandard'
   
   export default neostandard({
     // options
   })

   Or as CommonJS:

   module.exports = require('neostandard')({
     // options
   })

3. Run neostandard by running ESLint, eg. using npx eslint, npx eslint --fix or similar

Configuration options

• env - string[] - adds additional globals by importing them from the globals npm module
• files - string[] - additional file patterns to match. Uses the same shape as ESLint files
• filesTs - string[] - additional file patterns for the TypeScript configs to match. Uses the same shape as ESLint files
• globals - string[] | object - an array of names of globals or an object of the same shape as ESLint languageOptions.globals
• ignores - string[] - an array of glob patterns for files that the config should not apply to, see ESLint documentation for details
• noJsx - boolean - if set, no jsx rules will be added. Useful if for some reason its clashing with your use of JSX-style syntax
• noStyle - boolean - if set, no style rules will be added. Especially useful when combined with Prettier, dprint or similar
• semi - boolean - if set, enforce rather than forbid semicolons (same as semistandard did)
• ts - boolean - if set, TypeScript syntax will be supported and *.ts (including *.d.ts) will be checked. To add additional file patterns to the TypeScript checks, use filesTs

Extending

The neostandard() function returns an ESLint config array which is intended to be exported directly or, if you want to modify or extend the config, can be combined with other configs like any other ESLint config array:

import neostandard from 'neostandard'
import jsdoc from 'eslint-plugin-jsdoc';

export default [
  ...neostandard(),
  jsdoc.configs['flat/recommended-typescript-flavor'],
]

Do note that neostandard() is intended to be a complete linting config in itself, only extend it if you have needs that goes beyond what neostandard provides, and open an issue if you believe neostandard itself should be extended or changed in that direction.

It's recommended to stay compatible with the plain config when extending and only make your config stricter, not relax any of the rules, as your project would then still pass when using just the plain neostandard-config, which helps people know what baseline to expect from your project.

Additional exports

resolveIgnoresFromGitignore()

Finds a .gitignore file that resides in the same directory as the ESLint config file and returns an array of ESLint ignores that matches the same files.

ESM:

import neostandard, { resolveIgnoresFromGitignore } from 'neostandard'

export default neostandard({
  ignores: resolveIgnoresFromGitignore(),
})

CommonJS:

module.exports = require('neostandard')({
  ignores: require('neostandard').resolveIgnoresFromGitignore(),
})

Exported plugins

neostandard exports all the ESLint plugins that it uses. This to ensure that users who need to reference the plugin themselves will use the exact same instance of the plugin, which is a necessity when a plugin prefix is defined in multiple places.

List of exported plugins

• @stylistic - export of @stylistic/eslint-plugin
• n - export of eslint-plugin-n
• promise - export of eslint-plugin-promise
• react - export of eslint-plugin-react
• typescript-eslint - export of typescript-eslint

Usage of exported plugin

If one eg. wants to add the eslint-plugin-n recommended config, then one can do:

import neostandard, { plugins } from 'neostandard'

export default [
  ...neostandard(),
  plugins.n.configs['flat/recommended'],
]

Missing for 1.0.0 release

• Migrate eslint-plugin-import rules from standard: #15
• Investigate a dedicated neostandard runner: #33 / #2

Full list in 1.0.0 milestone

Differences to standard / eslint-config-standard 17.x

• Open governance, resolving governance issue
• Built for ESLint 9
• Relies on ESLint flat config to bundle plugins rather than custom standard-engine
• Replaces deprecated ESLint style rules with eslint-stylistic rules
• Defaults to the standard behaviour of bundling JSX-support (ported from eslint-config-standard-jsx) with a noJsx option that deactivates it to match eslint-config-standard
• Built in options replaces need for separate modules
  • ts option makes *.ts files be checked as well (used to be handled by ts-standard)
  • semi option enforces rather than ban semicolons (used to be handled by semistandard)
  • noStyle option deactivates style rules (used to require something like eslint-config-prettier)

Relaxed rules

• @stylistic/comma-dangle – changed – set to ignore dangling commas in arrays, objects, imports, exports and is it set to warn rather than error
• @stylistic/no-multi-spaces – changed – sets ignoreEOLComments to true, useful for aligning comments across multiple line
• dot-notation – deactivated – clashes with the noPropertyAccessFromIndexSignature check in TypeScript
• n/no-deprecated-api – changed – changed to warn instead of error as they are not urgent to fix

Missing bits

• Some plugins are not yet supporting ESLint 9 or flat configs and has thus not yet been added. These are:
  • eslint-plugin-import

Config helper

You can use the provided CLI tool to generate a config for you:

neostandard --semi --ts > eslint.config.js

To see all available flags, run:

neostandard --help

Config migration

The CLI tool can also migrate an existing "standard" configuration from package.json:

neostandard --migrate > eslint.config.js

Migrations can also be extended, so to eg. migrate a semistandard setup, do:

neostandard --semi --migrate > eslint.config.js

Readme badges

Yes! If you use neostandard in your project, you can include one of these badges in your readme to let people know that your code is using the neostandard style.

[![neostandard javascript style](https://img.shields.io/badge/neo-standard-7fffff?style=flat&labelColor=ff80ff)](https://github.com/neostandard/neostandard)

[![neostandard javascript style](https://img.shields.io/badge/code_style-neostandard-7fffff?style=flat&labelColor=ff80ff)](https://github.com/neostandard/neostandard)

[![neostandard javascript style](https://img.shields.io/badge/code_style-neostandard-brightgreen?style=flat)](https://github.com/neostandard/neostandard)

Mission statement

Prior to the 1.0.0 release we are still rapidly evolving with fixes and improvements to reach rule parity with standard, hence more breaking changes will be experienced until then, as well as evolution of this statement

neostandard intends to set an expectable baseline for project linting that's descriptive of best practices rather than prescriptive of any opinionated approach.

Rule guidelines

1. neostandard rules describes current best practices in the community and help align developers, contributors and maintainers along those
2. neostandard rules are not a tool to promote changed practices within the community by prescribing new such practices
3. neostandard rule changes and additions should be aligned with projects prior to being released, by eg. sending PR:s to them to align them ahead of time. When new best practices are incompatible with current best practices, rules should first be relaxed to allow for both approaches, then be made stricter when the community has moved to the new approach
4. neostandard rule changes and additions should improve the description of project best practices, not prescribe new practices
5. neostandard should, when faced with no clear best practice, avoid adding such a rule as it risks becoming prescriptive rather than descriptive. If leaving out such a rule would make neostandard an incomplete baseline config, and the community is split between a few clear alternatives (such as semi), then making it configurable can enable it to still be added, but that should only be done in exceptional cases

Governance

neostandard is a community project with open governance.

See GOVERNANCE.md for specifics.

Used by

A subset of some of the projects that rely on neostandard:

• bcomnes/npm-run-all2 (https://github.com/bcomnes/npm-run-all2/pull/142)
• fastify/fastify (https://github.com/fastify/fastify/pull/5509)
• nodejs/undici (https://github.com/nodejs/undici/pull/3485)
• poolifier/poolifier
• uuidjs/uuid (https://github.com/uuidjs/uuid/pull/752)