mcollina/linting-neostandard-eslint9
Configures ESLint v9 flat config and neostandard for JavaScript and TypeScript projects, including migrating from legacy `.eslintrc*` files or the `standard` package. Use when you need to set up or fix linting with `eslint.config.js` or `eslint.config.mjs`, troubleshoot lint errors, configure neostandard rules, migrate from `.eslintrc` to flat config, or integrate linting into CI pipelines and pre-commit hooks.
96
96%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
migration-from-standard.mdrules/
- name:
- migration-from-standard
- description:
- Accurate migration path from standard to neostandard on ESLint v9
- metadata:
- {"tags":"standard, neostandard, eslint, eslint9, migration, flat-config"}
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
- Install dependencies:
npm install --save-dev neostandard eslint- (Optional preflight) verify helper command works:
npx neostandard --help- Generate migrated config from existing
package.json"standard"settings:
npx neostandard --migrate > eslint.config.js- Replace lint scripts/CI commands from
standardtoeslint:
{
"scripts": {
"lint": "eslint .",
"lint:fix": "eslint . --fix"
}
}- Cleanup old setup:
npm uninstall standardThen 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-enginewrapper) - rule implementation uses modern flat-config/plugin model
- some rules differ from legacy standard/
eslint-config-standardbehavior - on neostandard v1+, import rules from
eslint-plugin-import-xare not bundled by default
If you relied heavily on import linting in your old setup, either:
- add
eslint-plugin-import-xexplicitly, 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.