mirror of
https://github.com/lucide-icons/lucide.git
synced 2026-11-11 13:28:19 +00:00
e042fec3b5
`lucide-react` and `lucide-react-native` both ship `.d.ts` files that import React types (`ForwardRefExoticComponent`, `SVGProps`, `RefAttributes`, `ReactNode`), but neither package declares `@types/react`. Under a hoisted `node_modules` this resolves by accident, so the gap is invisible in normal testing. It does not resolve under a strict layout — most notably pnpm's global virtual store (`enableGlobalVirtualStore`), where each package is linked from a store path outside the consuming repo. TypeScript resolves a package's imports relative to where that package physically lives and ignores `NODE_PATH`, so `react` resolves to the untyped `react/index.js`. Every icon's props silently degrade to `any`, and consumers hit implicit-any errors on their own callbacks under `noImplicitAny`. `skipLibCheck: true` hides the errors inside the `.d.ts` itself, which is why this survives most typechecks. Declaring the typings package as a peer dependency (rather than a hard dependency) lets it dedupe against whatever `@types/react` the consumer already has. `peerDependenciesMeta` marks it optional so JS-only consumers get no unmet-peer warning. Verified by packing each package and installing the tarball into a scratch consumer with `pnpm --virtual-store-dir` pointing outside the consumer, then typechecking with `skipLibCheck: false` and a `@ts-expect-error` probe on a nonexistent icon prop — a positive type assertion keeps passing when types widen to `any`, so it would not catch a regression. Before the change the probe reports `TS2578: Unused '@ts-expect-error' directive` plus `TS7016` inside the shipped `.d.ts`; after it, `tsc` is clean and `--traceResolution` shows `react` resolving to `@types/react/index.d.ts` instead of `react/index.js`. Existing peer ranges are unchanged and the lockfile is unaffected. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Eric Fennis <eric.fennis@gmail.com>