config-react-lib/README.md
2026-01-30 11:55:41 -08:00

81 lines
2.7 KiB
Markdown

# @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.
```typescript
// ❌ BAD - Will break when consumed
import { usePayment } from '@/hooks/usePayment';
// ✅ GOOD - Works when consumed
import { usePayment } from '../hooks/usePayment';
```
## Installation
```bash
pnpm add -D @lilith/eslint-config-react-lib
```
## Usage
```javascript
// .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.