Linting Neostandard Eslint9

When to use

Use this skill when you need to:

• Set up linting in a JavaScript or TypeScript project
• Use neostandard as a Standard-like ESLint v9 flat-config baseline
• Configure eslint@9 with the flat config system (eslint.config.js/eslint.config.mjs)
• Migrate from standard to neostandard or ESLint v9
• Migrate from legacy .eslintrc* configuration to ESLint v9
• Run linting consistently in CI and local development

Quick start: basic neostandard setup

Install dependencies and create a minimal eslint.config.js:

npm install --save-dev eslint@9 neostandard

// eslint.config.js
import neostandard from 'neostandard'

export default neostandard()

Verify the config works:

npx eslint .

Common setup workflow (new project)

1. Install eslint@9 and neostandard (see Quick start above) 2. Create eslint.config.js with neostandard() as the base 3. Add any project-specific rule overrides on top 4. Run npx eslint . to confirm no config errors 5. Add a lint script to package.json: "lint": "eslint ." 6. Integrate into CI with a non-fix run; use --fix only in local workflows

How to use

Read individual rule files for implementation details and examples:

• rules/neostandard.md - Install, configure, and extend neostandard with ESLint
• rules/eslint-v9-flat-config.md - Build ESLint v9 flat config for JS/TS projects
• rules/migration-from-standard.md - Migrate from standard to neostandard or ESLint v9
• rules/migration-from-legacy-eslint.md - Migrate from .eslintrc* to flat config safely
• rules/ci-and-editor-integration.md - CI scripts, pre-commit, and editor setup

Core principles

• Prefer reproducible linting with pinned major versions
• Keep config minimal and explicit
• Use flat config for ESLint v9 projects
• Treat lint failures as quality gates in CI
• Enable auto-fix for local workflows, but validate with non-fix CI runs

CI guidance

• Run lint in CI as a required step:

npm run lint

• Do not use auto-fix in CI.
• Keep CI Node.js version aligned with local development and project engines.

Pre-commit hook pattern

Use lint-staged (or equivalent) to lint only changed files before commit.

{
  "lint-staged": {
    "*.{js,mjs,cjs,ts,mts,cts}": [
      "eslint --fix"
    ]
  }
}

When using neostandard, keep pre-commit execution on eslint --fix because ESLint is the actual runner.

VS Code integration

• Install ESLint extension
• Enable flat config support if required by extension version
• Use editor.codeActionsOnSave for explicit, predictable auto-fixes

Example workspace settings:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },
  "eslint.validate": ["javascript", "typescript"]
}

ESLint v9 uses flat config by default. Prefer eslint.config.js or eslint.config.mjs over legacy .eslintrc* files.

Preferred setup in this skill: neostandard baseline

Install:

npm install --save-dev eslint neostandard

Create config (ESM helper):

npx neostandard --esm > eslint.config.js

Run lint:

npx eslint .

Manual flat config (when not using neostandard)

Install (example):

npm install --save-dev eslint @eslint/js typescript-eslint

Basic eslint.config.mjs (JS + TS):

import js from '@eslint/js'
import tseslint from 'typescript-eslint'

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ['**/*.{js,mjs,cjs,ts,mts,cts}'],
    languageOptions: {
      ecmaVersion: 'latest',
      sourceType: 'module'
    },
    rules: {
      'no-unused-vars': 'off',
      '@typescript-eslint/no-unused-vars': ['error', { argsIgnorePattern: '^_' }]
    }
  }
]

Package scripts

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

Good practices

• Use a single root flat config unless package-level variance is required
• Keep TypeScript-aware rules scoped to TS files
• Avoid duplicate JS/TS rules; disable base rule when TS extension rule is used
• Keep CI on non-fix lint runs; reserve --fix for local workflows

Use this checklist to migrate with low risk.

Migration checklist

1. Upgrade ESLint major version:

   npm install --save-dev eslint@^9

2. Create eslint.config.js or eslint.config.mjs 3. Translate legacy extends, plugins, and overrides into flat-config entries 4. Remove .eslintrc* and deprecated ignore files once parity is verified 5. Run lint and compare issue count before/after migration 6. Fix rule parity gaps explicitly in config 7. Update CI scripts to call eslint .

Pitfalls to avoid

• Mixing legacy and flat config in the same project
• Forgetting to disable base rules when TS variants are enabled
• Assuming plugin presets are flat-config compatible without checking docs
• Migrating config and rule semantics in a single large change without validation

Use this when a project currently runs standard and you want modern ESLint v9 + flat config while keeping a Standard-like baseline.

Canonical migration flow

1. Install dependencies:

npm install --save-dev neostandard eslint

2. (Optional preflight) verify helper command works:

npx neostandard --help

3. Generate migrated config from existing package.json "standard" settings:

npx neostandard --migrate > eslint.config.js

4. Replace lint scripts/CI commands from standard to eslint:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

5. Cleanup old setup:

npm uninstall standard

Then remove obsolete top-level "standard" config and editor integrations specific to standard (for example vscode-standard).

Semicolon and TypeScript variants

• semistandard-like migration:

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

• TypeScript support in resulting config: set ts: true (or regenerate/configure accordingly).

Behavioral differences to expect

• neostandard is built for ESLint 9 flat config (no standard-engine wrapper)
• rule implementation uses modern flat-config/plugin model
• some rules differ from legacy standard/eslint-config-standard behavior
• on neostandard v1+, import rules from eslint-plugin-import-x are not bundled by default

If you relied heavily on import linting in your old setup, either:

• add eslint-plugin-import-x explicitly, or
• rely on tsc --noEmit (recommended for TypeScript-heavy projects)

Run lint and fix incrementally after migration; keep tooling migration separate from rule-tuning commits.

neostandard is a shared ESLint flat config and config generator, not a standalone replacement linter command.

Key model

• You install both neostandard and eslint
• You generate or author eslint.config.js / eslint.config.mjs
• You run linting via eslint (eslint ., eslint . --fix)

Install

npm install --save-dev neostandard eslint

Create config

Generate ESM config:

npx neostandard --esm > eslint.config.js

Generate CommonJS config:

npx neostandard > eslint.config.js

Or author manually (ESM):

import neostandard from 'neostandard'

export default neostandard({
  ts: true
})

Run lint

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix"
  }
}

Common options

• ts: true — lint *.ts and *.d.ts
• semi: true — semicolon mode (semistandard-style)
• noStyle: true — disable style rules (useful with Prettier/dprint)
• noJsx: true — disable JSX rules
• ignores, files, filesTs, env, globals

Version caveat (v1+)

As of neostandard v1+, eslint-plugin-import-x is no longer bundled.

• If you need deep import/export lint rules, add eslint-plugin-import-x explicitly
• For many TypeScript projects, prefer tsc --noEmit for module/import correctness checks

Useful export

Use .gitignore patterns as ESLint ignores:

import neostandard, { resolveIgnoresFromGitignore } from 'neostandard'

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

Important migration note

For projects moving from standard, keep neostandard as the config source but run lint through eslint.