| author | agents |
|---|---|
| status | normative |
| last_reviewed | 2026-03-05 |
| source_of_truth_scope | naming, file structure, exports/imports, and React module hygiene |
- Prefer explicit suffixes:
*.container.tsx,*.pure.tsx,*.styled.ts,*.types.ts,*.constants.ts,*.utils.ts,*.service.ts,*.test.ts
- Hooks are the naming exception and should use
useX.ts/useX.tsx. - Avoid generic filenames like
styledunless the file is intentionally a barrel or module entry.
- Prefer named exports over default exports.
- Keep component file exports focused (component + component-specific types).
- Re-export public module APIs from
index.ts.
- Within a module, use relative imports for module internals.
- For shared app code, use aliases (
common/...,modules/...) instead of long relative traversals. - Avoid deep internal imports across module boundaries unless explicitly justified.
- Follow repository
import/orderlint rules.
- Do not define components inside render bodies.
- Avoid helper factories that return JSX on hot render paths.
- Keep stable list keys; do not generate random keys per render.
- Prefer extraction/composition over pass-through wrapper components.
- Keep Lingui
t\`/t()` calls inside components or functions. - Do not place translation calls at module scope.
- Use
styled-components/macro(not rawstyled-components). - Keep style-only files in
*.styled.tswhen styles are non-trivial. - In cowswap-frontend modules, style imports should use:
import * as styledEl from './X.styled'
strictNullChecksassumptions apply.- Never use
anyfor production code; prefer specific types orunknown. - No non-null assertions (
!). - Use enums/unions from upstream SDK/types instead of raw string literals.