feat(scripts/generate-phosphor-icon-registry): reject bare icon names via a generated module declaration - #1099
Conversation
… via a generated module declaration
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe icon registry generator now creates a TypeScript declaration for ChangesPhosphor icon registry
Estimated code review effort: 3 (Moderate) | ~15–30 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
tanstack-com | 2c7a755 | Commit Preview URL Branch Preview URL |
Aug 03 2026, 12:47 AM |
Follow-up to #1094, implementing @SeanCassiere's suggestion there.
#1094 renamed every icon import to the
Icon-suffixed export, but the deprecated spelling is still exported, soimport { Star }remains a strikethrough rather than an error — nothing stops the old names from creeping back.Phosphor doesn't ship a suffixed-only entrypoint like Lucide's
lucide-react.suffixed, soexport * from '...'has nothing to point at: the barrel doesexport * from './csr/Star'×1512, and each icon module exports bothStarandStarIcon. Redeclaring the module with only the suffixed members gets the same result.Changes
scripts/generate-phosphor-icon-registry.mjsnow emits a second artifact,src/types/phosphor-icons.generated.d.ts, from the samedist/csrscan that already builds the DS registry. It declares@phosphor-icons/reactwith the 1512 suffixed exports plus the barrel's non-icon members (Icon,IconProps,IconWeight,IconContext,IconBase,SSR) — the ambient declaration replaces the barrel's types wholesale, so omitting any of those would break every consumer of them.Validation
Subpaths in the declaration follow the package's own
exportsmap (./lib,./ssr,./*). This matters more than it looks: pointing at the underlyingdist/libpath instead resolves to nothing, and withskipLibCheck: truethat failure is silent — every re-exported symbol quietly degrades toany. An import-only smoke test passes either way, so correctness was checked negatively:const w: IconWeight = 'nope'→ TS2322<StarIcon weight="nope" />→ TS2322<StarIcon notAProp={1} />→ TS2322import { Star }→ TS2305import { StarIcon }, the five non-icon exports, and subpath imports (@phosphor-icons/react/Acorn, used by the generated registry) → cleantsc --skipLibCheck falsereports nothing originating in the generated declarationpnpm testpasses (143 tests, 1 environment-gated skip); oxlint and oxfmt clean; re-runningicons:generateis a no-op.Known limitations
SSR.Starstill resolves. The namespace re-export passes the SSR module through untouched, so bare names survive behindSSR.*. Nothing insrc/importsSSR, so this is a stated gap rather than a regression.@phosphor-icons/reactrequires re-runningpnpm icons:generate. Until then a newly added icon isn't in the declaration, and a valid import reads as TS2305. A CI drift check would close this; it isn't included here.Summary by CodeRabbit