@hyperse/eslint-config-hyperse

🛠 A comprehensive ESLint and Prettier configuration for TypeScript projects, with support for monorepos and ESM. Optimized for Next.js and React applications. ⚡️

Features

• 🎯 TypeScript & JavaScript Linting: Latest standards-based linting for both TypeScript and JavaScript
• 🔧 Multiple Config Presets: Ready-to-use configurations for react, hooks, next, and more
• 📝 Shared TypeScript Config: Pre-configured tsconfig.json for consistent TypeScript settings
• 💅 Prettier Integration: Automatic code formatting with sensible defaults
• ♿️ Accessibility: Built-in rules for JSX accessibility
• 📦 Monorepo Support: Optimized for monorepo setups
• 🔄 Module Support: Full compatibility with both ESM and CommonJS
• 🎨 Tailwind CSS: Built-in support for Tailwind CSS class sorting
• 🔍 SonarJS: Optional integration for code quality rules

Installation & Configuration

Basic Setup

1. Initialize your project (if needed):

   npm init
   

2. Install the ESLint config:

   npm i -D @hyperse/eslint-config-hyperse
   

3. Create ESLint configuration:

   • Create eslint.config.js (or eslint.config.mjs for CommonJS) in your project root
   • Add the base configuration:

TypeScript Configuration

Compiler defaults

The shared config targets ES2023 and pins lib explicitly to ["ES2023", "DOM", "DOM.Iterable", "DOM.AsyncIterable", "WebWorker.ImportScripts", "ScriptHost"], so the built-in type declarations no longer depend on the target default. Projects needing newer built-ins can opt in without forking the base config:

Base Configuration (tsconfig.json)

Build Configuration (tsconfig.build.json)

Available Scripts

Add to your package.json:

Or for JavaScript-only projects:

Framework-Specific Configurations

Next.js

React.js (without Next.js)

SonarJS Integration

VS Code Integration

1. Install the ESLint extension

2. Configure VS Code settings (.vscode/settings.json):

Additional Configuration

Prettier Configuration

Use definePrettierConfig() so Prettier CLI matches ESLint prettier/prettier (base options and prettier-plugin-tailwindcss, with the plugin always last when you add more plugins). The name mirrors this package’s defineConfig helper for ESLint.

Create prettier.config.mjs:

Optional slim import (no ESLint stack): @hyperse/eslint-config-hyperse/definePrettierConfig (the legacy path @hyperse/eslint-config-hyperse/getPrettierConfig still resolves to the same module).

The previous name getPrettierConfig remains exported but is deprecated; prefer definePrettierConfig.

Tailwind CSS Integration

Configure Tailwind via definePrettierConfig (paths are resolved relative to this config file):

Important Notes

• TypeScript settings:
  • isolatedModules: true (default)
  • verbatimModuleSyntax: true (default)
• JSON/JSONC files: VS Code formatting is disabled by default
• React ESLint rules: See source code

Performance Considerations

The following ESLint rules may impact performance during linting/formatting:

• prettier/prettier: Can be slow on large files due to full reformatting
• sonarjs/arguments-order: Complex analysis of function argument usage patterns

Consider selectively disabling these rules for specific files if performance becomes an issue.

@typescript-eslint/no-deprecated is opt-in

This rule is the only type-aware rule the preset ships, and it is disabled by default because enabling it is what pushes eslint . past the default Node heap on larger repositories.

Measured on a ~2k-file monorepo package spanning 4 TS projects, from repeated runs against the default Node heap (~4GB):

TIMING=1 also shows the rule consuming ~27.8s of rule time — 62% of the total, and ~2.3x the next most expensive rule (prettier/prettier at ~12.1s).

Re-enable it per project when the repository is small enough to afford it:

Keep the files selector, and don't enable it with the CLI --rule flag. --rule applies to every file ESLint visits, not just TypeScript. Files matched by other configs — .json among them — carry no parserOptions, so the run aborts with:

Error while loading rule '@typescript-eslint/no-deprecated':

projectService stays on, and why

projectService builds a TypeScript program covering every linted file, and that program is where the remaining >3GB of heap goes. It is kept enabled because @typescript-eslint/consistent-type-imports depends on it for correctness, not just accuracy.

The rule reads emitDecoratorMetadata and experimentalDecorators from parser services and, when both are set, skips any file containing a decorator (typescript-eslint#5468). Imports in those files are still referenced at runtime through design:type metadata, so rewriting them with import type changes behaviour.

Without the program that guard is silently disabled. On the package above, turning projectService off made the rule report 615 new errors — e.g. in a TypeORM entity where the import is used only in a decorated property:

The suggested autofix would turn that into import type, replacing the emitted metadata with Object. That is why this preset keeps projectService on by default.

If you want the ~512MB heap instead and do not rely on consistent-type-imports, turn both off together:

Configure it in eslint.config.js as above instead.