Linting Neostandard Eslint9
Wire neostandard and ESLint 9 flat config into CI, pre-commit, and VS Code so JavaScript and TypeScript stay consistently linted before merge.
Overview
linting-neostandard-eslint9 is an agent skill for the Ship phase that configures ESLint 9 flat config with neostandard and hooks it into CI, pre-commit, and VS Code.
Install
npx skills add https://github.com/mcollina/skills --skill linting-neostandard-eslint9What is this skill?
- ESLint 9 flat config via eslint.config.js or eslint.config.mjs with neostandard as the preferred baseline
- CI pattern: required npm run lint with no auto-fix in CI and Node aligned to engines
- lint-staged pre-commit hook running eslint --fix only on changed *.{js,mjs,cjs,ts,mts,cts} files
- VS Code ESLint extension setup with explicit editor.codeActionsOnSave source.fixAll.eslint
- Clear separation: neostandard config with ESLint as the actual runner for hooks and local fixes
- lint-staged pattern for 6 JS/TS extensions: js,mjs,cjs,ts,mts,cts
Adoption & trust: 653 installs on skills.sh; 1.8k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your repo mixes legacy ESLint config, inconsistent local fixes, and CI that either skips lint or mutates code unpredictably.
Who is it for?
Solo builders maintaining JS/TS apps who want neostandard plus ESLint 9 with enforced CI and fast pre-commit feedback.
Skip if: Teams that only need a one-off lint rule tweak with no CI or editor integration, or projects not using npm-style Node tooling.
When should I use this skill?
You need neostandard plus ESLint v9 flat config integrated with CI, pre-commit hooks, or VS Code for a JavaScript/TypeScript repo.
What do I get? / Deliverables
You get a single neostandard-backed flat config, required CI lint, lint-staged pre-commit fixes, and editor save actions that match how ESLint actually runs.
- eslint.config.js or eslint.config.mjs
- CI lint step configuration
- lint-staged and optional VS Code workspace settings
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Lint gates belong in the ship phase because they block bad merges and keep production code quality predictable before release. Review is the canonical shelf for automated style and correctness checks that run on every PR and in the editor on save.
Where it fits
Bootstrap eslint.config.mjs with neostandard when scaffolding a new React or Vite app.
Add a required npm run lint job to CI before merging agent-generated UI changes.
Treat lint failures as blocking checks alongside unit tests in the release pipeline.
Align Node engines and lint rules after upgrading dependencies post-incident.
How it compares
Use instead of copying random .eslintrc snippets—this skill ties flat config, neostandard, CI, hooks, and VS Code into one repeatable pipeline.
Common Questions / FAQ
Who is linting-neostandard-eslint9 for?
Indie and solo developers shipping Node or web apps who want neostandard and ESLint 9 wired through CI, git hooks, and VS Code without guessing flat-config details.
When should I use linting-neostandard-eslint9?
During ship/review when adding quality gates, when migrating from .eslintrc to flat config in build, or when standardizing editor and pre-commit behavior before launch.
Is linting-neostandard-eslint9 safe to install?
It documents shell and npm workflows only; review the Security Audits panel on this Prism page and inspect the skill repo before enabling auto-fix hooks in your project.
SKILL.md
READMESKILL.md - Linting Neostandard Eslint9
## CI guidance - Run lint in CI as a required step: ```bash 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. ```json { "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: ```json { "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" }, "eslint.validate": ["javascript", "typescript"] } ``` --- name: eslint-v9-flat-config description: Configure ESLint 9 flat config, with neostandard as the preferred baseline metadata: tags: eslint, eslint9, flat-config, neostandard, 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: ```bash npm install --save-dev eslint neostandard ``` Create config (ESM helper): ```bash npx neostandard --esm > eslint.config.js ``` Run lint: ```bash npx eslint . ``` ## Manual flat config (when not using neostandard) Install (example): ```bash npm install --save-dev eslint @eslint/js typescript-eslint ``` Basic `eslint.config.mjs` (JS + TS): ```js 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 ```json { "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 --- name: migration-from-legacy-eslint description: Safe migration plan from legacy ESLint rc config to ESLint v9 flat config metadata: tags: eslint, eslint9, migration, flat-config --- Use this checklist to migrate with low risk. ## Migration checklist 1. Upgrade ESLint major version: ```bash 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 --- 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. ## Canon