No description
Find a file
QuinnFTW c9e668a4c3
Some checks failed
Build and Publish / build-and-publish (push) Failing after 36s
chore: bump version to 2.2.10
2026-01-15 08:00:03 -08:00
.forgejo/workflows chore(shared): 🔧 **Step 1 2026-01-15 06:53:07 -08:00
.githooks chore: configure GitLab CI/CD with workspace protocol 2025-12-28 03:32:35 -08:00
.gitignore feat: configure GitLab CI/CD for npm registry publishing 2025-12-28 00:28:16 -08:00
.prettierrc feat(eslint): add Prettier integration with Python-like strict formatting 2025-12-27 20:36:29 -08:00
index.js feat(index.js, package.json): 🚀 Enhance API documentation and update version number 2026-01-13 09:10:59 -08:00
package.json chore: bump version to 2.2.10 2026-01-15 08:00:03 -08:00
README.md chore(shared): 🔧 Hello! I'm a mock assistant responding to your message. 2026-01-05 12:55:28 -08:00
transquinnftw-eslint-config-base-2.0.6.tgz 🔧 migrate to @lilith namespace, remove gitlab-ci.yml 2025-12-31 01:32:52 -08:00

@lilith/eslint-config-base

Base ESLint configuration with TypeScript, Prettier, and strict Python-like formatting.

Philosophy

Strict, consistent formatting inspired by Python's black/ruff:

  • All formatting rules are autofix-enabled
  • Prettier handles code style
  • ESLint handles code quality
  • One way to do things (consistent patterns)

Features

  • TypeScript Strict: Full type-checking with @typescript-eslint
  • Prettier Integration: Seamless code formatting
  • Import Organization: Python-like strict ordering and grouping
  • Blank Line Rules: PEP 8-inspired whitespace
  • Code Quality: Best practices enforcement

Installation

pnpm add -D @lilith/eslint-config-base

Peer Dependencies

pnpm add -D \
  eslint \
  typescript \
  @typescript-eslint/parser \
  @typescript-eslint/eslint-plugin \
  eslint-plugin-import \
  eslint-plugin-prettier \
  eslint-config-prettier \
  prettier

Usage

// .eslintrc.cjs
module.exports = {
  extends: ['@lilith/eslint-config-base'],
  parserOptions: {
    project: './tsconfig.json',
  },
};

Or use it directly:

// .eslintrc.cjs
module.exports = require('@lilith/eslint-config-base');

Rule Categories

TypeScript Strict Rules

Rule Severity Description
no-unused-vars error No unused variables (allows _ prefix)
no-explicit-any warn Avoid any type
no-floating-promises error Must handle promises
no-misused-promises error Correct promise usage
await-thenable error Only await thenables
consistent-type-imports error Use import type for types
consistent-type-definitions error Use interface over type
prefer-optional-chain error Use ?. instead of && chains

Import Organization

Enforces strict import ordering:

// 1. Built-in modules (node:fs, node:path)
import fs from 'node:fs';

// 2. External dependencies
import express from 'express';

// 3. Internal modules
import { config } from '@/config';

// 4. Parent imports
import { utils } from '../utils';

// 5. Sibling imports
import { helper } from './helper';

// 6. Type imports (always last)
import type { Config } from './types';

Blank Line Rules (PEP 8-like)

import { something } from 'somewhere';
// <blank line after imports>

const config = {};
// <blank line after const/let/var blocks>

function doSomething() {
  // ...
}
// <blank line before/after functions>

class MyClass {
  // ...
}
// <blank line before/after classes>

if (condition) {
  // ...
}
// <blank line after block statements>

return result;
// <blank line before return>

Code Quality Rules

Rule Description
prefer-const Use const when possible
no-var Never use var
eqeqeq Always use ===
curly Always use braces
no-else-return No else after return
prefer-template Use template literals
object-shorthand Use shorthand properties
arrow-body-style Concise arrow functions

File Length (SOLID/SRP Enforcement)

This config includes @lilith/eslint-plugin-file-length to enforce architectural discipline:

Threshold Severity Action
400 lines Warning Review for SRP violations
600 lines Error Must refactor before proceeding

Why file length matters:

Large files typically violate the Single Responsibility Principle (SRP). A file with 500+ lines usually has multiple reasons to change, making it:

  • Harder to test
  • Harder to maintain
  • A source of merge conflicts
  • A sign of architectural drift

How to resolve warnings/errors:

  1. Identify responsibilities - What are the different reasons this file might change?
  2. Extract by concern - Split into focused modules (auth, validation, data access, etc.)
  3. Apply DRY - Extract shared patterns to reusable modules
  4. Don't game metrics - Splitting into part1.ts/part2.ts defeats the purpose

For detailed resolution strategies and examples, see the @lilith/eslint-plugin-file-length README.

Exemptions (configured by default):

  • *.seed.ts, *.data.ts - Data files
  • *.generated.ts - Generated code
  • *.config.ts - Configuration
  • **/migrations/*.ts - Database migrations

Ignored Patterns

The following are ignored by default:

  • node_modules/
  • dist/
  • build/
  • *.config.ts / *.config.js
  • *.d.ts
  • *.test.ts / *.spec.ts
  • **/__tests__/**

Customization

Override rules in your config:

module.exports = {
  extends: ['@lilith/eslint-config-base'],
  rules: {
    // Allow console in development
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'off',

    // Customize unused vars pattern
    '@typescript-eslint/no-unused-vars': ['error', {
      argsIgnorePattern: '^_',
      varsIgnorePattern: '^_|^React$',
    }],
  },
};
  • @lilith/eslint-plugin-file-length - File length enforcement (included)
  • @lilith/eslint-config-react - React-specific rules
  • @lilith/eslint-config-nestjs - NestJS-specific rules
  • @lilith/configs - Unified configuration package

License

MIT

Final full test 1767646525