No description
| .forgejo/workflows | ||
| node_modules/.bin | ||
| index.js | ||
| package.json | ||
| README.md | ||
@lilith/eslint-config-react-lib
ESLint configuration for React libraries.
When to Use
Use this config for React code that is consumed as a dependency by other packages:
- Payment UI components (
features/payments/frontend-checkout) - Shared component libraries
- Any feature with
"exports"in package.json
When NOT to Use
Do NOT use for standalone React applications:
- Landing pages
- Admin dashboards
- User portals
For applications, use @lilith/eslint-config-react-app instead.
What It Adds
Extends @lilith/eslint-config-react with stricter library rules:
| Rule | Effect | Reason |
|---|---|---|
no-console |
Warn on console.log | Libraries shouldn't pollute consumer logs |
explicit-module-boundary-types |
Warn on missing types | Consumers need explicit types |
consistent-type-exports |
Warn on mixed exports | Clean type imports for consumers |
What It Does NOT Include
No @/ import alias rules. Libraries must use relative imports because:
When a library is symlinked into a consumer (via workspace:*), @/ aliases resolve against the consumer's tsconfig, not the library's. This causes build failures.
// ❌ BAD - Will break when consumed
import { usePayment } from '@/hooks/usePayment';
// ✅ GOOD - Works when consumed
import { usePayment } from '../hooks/usePayment';
Installation
pnpm add -D @lilith/eslint-config-react-lib
Usage
// .eslintrc.js
module.exports = {
extends: ['@lilith/eslint-config-react-lib'],
};
Why Relative Imports for Libraries?
Consumer (landing) Library (payments)
┌─────────────────────┐ ┌────────────────────────┐
│ node_modules/ │ symlink │ frontend-checkout/ │
│ @lilith/payments/ │ ──────────── │ components/Foo.tsx │
│ │ │ import '@/hooks' │
└─────────────────────┘ └────────────────────────┘
↓
Vite resolves @/ using
LANDING's tsconfig
↓
Looks for /landing/src/hooks
↓
BUILD FAILURE ❌
Relative imports don't have this problem - they resolve from the file's actual location.