Skip to content

noctcore ESLint plugins

A family of focused ESLint plugins that encode architecture and correctness conventions generic linters can't see. Cross-file boundaries, IO contracts, and code that compiles but bites in production.

Yes, if you run a TypeScript codebase on ESLint 9 or newer with flat config, and the bugs that reach review are structural: a component that drills props five levels down, a fetch with no timeout, a Prisma write outside its transaction, a log line that interpolates a user’s email. These plugins catch those with high-precision, mostly syntactic rules, and every rule is error or off, never warn (why).

Probably not, if you are on legacy .eslintrc config (these are flat-config only), you want a general style guide (use typescript-eslint and a formatter; these plugins assume both), or your codebase does not share the conventions a plugin encodes. Each package page says when it is a bad fit.

Every package is independently versioned. Install the one that matches the problem you have.

Looking for one rule? Every rule on one page, across all packages.

Pick a package. Each tab is the install command and a working eslint.config.js.

Install
npm install --save-dev @noctcore/eslint-plugin-react @typescript-eslint/parser
# or: bun add -D / pnpm add -D @noctcore/eslint-plugin-react @typescript-eslint/parser
eslint.config.js
// eslint.config.js
import tsParser from '@typescript-eslint/parser';
import react from '@noctcore/eslint-plugin-react';
export default [
{
...react.configs.recommended,
files: ['**/*.{ts,tsx}'],
languageOptions: { parser: tsParser },
},
];

The recommended preset enables 14 of 14 rules.

Each rule page on this site is generated from the Markdown file that ships inside the npm tarball (docs/rules/<rule>.md), and the tables are generated from each plugin’s exported rule metadata. The Incorrect and Correct examples on every rule page are executed by that package’s test suite, so an example that stops matching the rule fails CI before it can reach this page.