[code-infra] Upgrade react-docgen to v8 by JCQuintas · Pull Request #47685 · mui/material-ui

JCQuintas · 2026-01-26T20:46:21Z

Remove unnecessary types
Small fixes for changes in v6, v7 and v8
Should support newer typescript
Most stuff done by claude
There is a lot of prop?. that are needed, we weren't taking that they were undefined before, current types should be better as they come from the lib
There is also an issue where the actual typedocs are duplicated if the props of an object are declared multiple times. hover on the prop value
- This PR prevents it by displaying that in the propTypes/docs, so our devs are aware of it. A side-effect is that I had to "clean" some of the types in the code.
  1. ExtendButtonBaseTypeMap (ButtonBase.d.ts): Added dynamic Omit to exclude props that child types redefine
  2. ExtendPaperTypeMap (Paper.d.ts): Same pattern to prevent children and sx duplication in Accordion, AppBar, etc.
  3. ExtendListTypeMap (List.d.ts): Same pattern to prevent children duplication in MenuList
  4. StyledComponentProps (styles/index.d.ts): Removed JSDoc to prevent classes duplication
  5. TransitionProps (transitions/transition.ts): Defined addEndListener locally with JSDoc to avoid duplication from external react-transition-group types
  6. Select.d.ts:
  - Removed variant from BaseSelectProps (moved JSDoc to OutlinedSelectProps only)
  - Added 'defaultValue' | 'sx' to Omit in all variant interfaces
  1. TextField.d.ts: Restructured variant interfaces to use indexed access types for slots/slotProps without inheriting duplicate JSDoc
  2. AccordionSummary.d.ts: Added JSDoc to children prop since it was no longer inherited
  3. SwipeableDrawer.d.ts: Made SwipeableDrawerSlots extend DrawerSlots and used single CreateSlotsAndSlotProps to avoid duplicate slots/slotProps JSDoc

mui-bot · 2026-01-26T20:47:30Z

Netlify deploy preview

https://deploy-preview-47685--material-ui.netlify.app/

Bundle size report

Bundle	Parsed size	Gzip size
@mui/material	0B^(0.00%)	0B^(0.00%)
@mui/lab	0B^(0.00%)	0B^(0.00%)
@mui/system	0B^(0.00%)	0B^(0.00%)
@mui/utils	0B^(0.00%)	0B^(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against 9da3f78

JCQuintas · 2026-01-27T20:59:41Z

@mui/infra This is currently working, we might want to divide some of the changes to isolate them, as I took some liberty in the path I took.

I want to hear your opinion on this though, before I go further.

My main motivation was to fix an issue with satisfies usage in X 🫠

Janpot · 2026-01-28T14:49:35Z

-      distinctDefinitions.set(definition.$$id, definition);
-    }
+    // Always update so that the last definition's jsDoc wins
+    // This ensures that when types are intersected (A & B), the last type's documentation is used


So it went from first to last definition wins?

Pretty much

Reasoning was more that usually we have

interface A extends B {} which is similar to A & B. It felt a bit arbitrary that the first wins, which would prevent some overriding.

Ideally the best way is to Omit<A, keyof B> & B though

interface A extends B {}

feels similar to

B & A

to me, as in A's props should win over Bs, but that isn't how this code interpretes it?

True, A should win in the first, but B should in the second. 🫠

I checked it on the playground

Inheritance picks the first time the prop appears 🙃
If you override it, then it ignores any previous declaration.

Intersection merges all declarations together.

I think ideally we take interface behavior, because that can't simply be altered to fix the comment. i.e.

interface X extends Y, Z { /** foo */ prop: number }

we can easily move Y and Z around, but we can't really reorder X. even though, if one comment should win, it's probably X here.

For types, we can freely change the order, so it doesn't really matter what we do in terms of "first wins" or "last wins", we can pick what interfaces do and adjust order where needed.

Instead of adding more Omit, maybe it's a matter of reordering the types in the intersection?

I've reworked it a bit to follow typescript, which required less changes in the end :)
Divided them into commits for each component, each with a vague-ish description of the reason 😆

In a few cases it still made sense to add Omit, else the types (when viewed by the user in a code editor) would still be merged/messy.

Janpot · 2026-01-28T15:03:32Z

Took the liberty of removing a few more as any

Janpot · 2026-01-28T15:09:48Z

Added dynamic Omit to exclude props that child types redefine

To me, the intuitive thing to do is that the comment on the prop of the overwrite wins, if there is one. Not sure if that's hard todo or not, but with that logic, do we really need to exclude props?

This reverts commit 120bcae.

This reverts commit 3caac7d.

siriwatknp

Nice, tested https://stackblitz.com/edit/xnxgc33z?file=src%2FDemo.tsx

…eclarations The `getSymbolDocumentation` function was introduced in mui#47685 to handle JSDoc merging across multiple TypeScript declarations. However, it unconditionally joined all unique JSDoc comments when a symbol had multiple declarations, which produced duplicated descriptions in the generated propTypes for interface declaration merging and module augmentation scenarios. TypeScript treats JSDoc differently depending on how declarations combine: - Intersection types (type C = A & B): all constituent JSDoc are merged - Interface extends (interface Z extends X, Y): first parent's JSDoc wins - Interface override (interface W extends X { prop }): the override's JSDoc wins - Declaration merging / module augmentation: last declaration's JSDoc wins The previous implementation treated all multi-declaration cases as intersections, concatenating distinct comments. This caused issues in downstream repos (e.g. mui-x) where module augmentation is used to extend interface props — the original and augmented JSDoc would both appear in the generated propTypes output. The fix now uses `parentType.isIntersection()` to distinguish intersection types (where merging is correct) from declaration merging (where the last declaration should win), matching TypeScript's own behavior. Added test cases for all four JSDoc resolution scenarios: - jsdoc-intersection: verifies both descriptions are merged - jsdoc-interface-extends: verifies first parent's description wins - jsdoc-interface-override: verifies override description wins - declaration-merging: verifies last (augmented) description wins

…eclarations The `getSymbolDocumentation` function was introduced in mui#47685 to handle JSDoc merging across multiple TypeScript declarations. However, it unconditionally joined all unique JSDoc comments when a symbol had multiple declarations, which produced duplicated descriptions in the generated propTypes for interface declaration merging, module augmentation, and intersection type scenarios. The previous implementation treated all multi-declaration cases as intersections and concatenated distinct comments. This caused issues in downstream repos (e.g. mui-x) where: - Module augmentation extends interface props (e.g. BarPlotProps onItemClick) - Intersection types combine types with overridden JSDoc (e.g. autoFocus in MultiInputDateRangeField where the field-specific description should replace the base HTML input description) The fix uses a simple "last declaration wins" rule for all cases with multiple declarations, consistent with `squashPropTypeDefinitions` which already uses the same approach. This correctly handles: - Declaration merging / module augmentation: augmentation wins - Intersection types: last constituent wins - Interface extends / override: override wins (single declaration) Added test cases for all four JSDoc resolution scenarios: - jsdoc-intersection: verifies last constituent's description wins - jsdoc-interface-extends: verifies first parent's description wins - jsdoc-interface-override: verifies override description wins - declaration-merging: verifies last (augmented) description wins This change has no affect on this repo and affects around 7 api/proptypes generation in X repo.

…eclarations The `getSymbolDocumentation` function was introduced in mui#47685 to handle JSDoc merging across multiple TypeScript declarations. However, it unconditionally joined all unique JSDoc comments when a symbol had multiple declarations, which produced duplicated descriptions in the generated propTypes for interface declaration merging, module augmentation, and intersection type scenarios. The previous implementation treated all multi-declaration cases as intersections and concatenated distinct comments. This caused issues in downstream repos (e.g. mui-x) where: - Module augmentation extends interface props (e.g. BarPlotProps onItemClick) - Intersection types combine types with overridden JSDoc (e.g. autoFocus in MultiInputDateRangeField where the field-specific description should replace the base HTML input description) The fix uses a simple "last declaration wins" rule for all cases with multiple declarations, consistent with `squashPropTypeDefinitions` which already uses the same approach. This correctly handles: - Declaration merging / module augmentation: augmentation wins - Intersection types: last constituent wins - Interface extends / override: override wins (single declaration) Added test cases for all four JSDoc resolution scenarios: - jsdoc-intersection: verifies last constituent's description wins - jsdoc-interface-extends: verifies first parent's description wins - jsdoc-interface-override: verifies override description wins - declaration-merging: verifies last (augmented) description wins This change has no effect on this repo and affects around 7 api/proptypes generation in X repo.

`getSymbolDocumentation` (introduced in mui#47685) concatenated JSDoc from all declarations when a symbol had multiple (intersection, declaration merging, module augmentation). This produced duplicated descriptions in generated propTypes. Fix: use "last declaration wins" for all multi-declaration cases, consistent with `squashPropTypeDefinitions`. Added tests for intersection, interface extends, interface override, and declaration merging scenarios. This change has no effect on this repo and affects around 7 api/proptypes generation in X repo.

JCQuintas added 4 commits January 26, 2026 18:52

[code-infra] Update docgen to v8 version

c15b02a

refactor

f558d76

fix handling object accessor egvalue.name

d358ba0

run script

d37263f

JCQuintas self-assigned this Jan 26, 2026

JCQuintas added type: enhancement It’s an improvement, but we can’t make up our mind whether it's a bug fix or a new feature. scope: code-infra Involves the code-infra product (https://www.notion.so/mui-org/5562c14178aa42af97bc1fa5114000cd). labels Jan 26, 2026

JCQuintas added 9 commits January 26, 2026 21:56

prettier

90e92a2

fix possible issues

74efc23

fix unknown

371dc84

remove unknown

dc2367c

get last version

82bc7e1

merge all declarations

0bb3470

fix typedoc duplications

3caac7d

fix prettier

66f2347

docs typescript

120bcae

JCQuintas marked this pull request as ready for review January 27, 2026 20:57

JCQuintas requested a review from a team January 27, 2026 20:57

JCQuintas added 2 commits January 28, 2026 14:19

fix type

1bb640d

prettier

dfc3689

Janpot reviewed Jan 28, 2026

View reviewed changes

few tweaks

d83fc71

JCQuintas added 4 commits January 28, 2026 18:31

Revert "docs typescript"

b0dd5fa

This reverts commit 120bcae.

Revert "fix typedoc duplications"

b0cd87a

This reverts commit 3caac7d.

rework

831c7f5

autocomplete readOnly inherited from useautocomplete

22076a6

github-actions Bot added the PR: out-of-date The pull request has merge conflicts and can't be merged. label Feb 18, 2026

JCQuintas added 2 commits February 18, 2026 08:37

fix prettier

5bf034f

Merge commit '1682b6cfea85951e503c9c2a812b7bbad8055af1' into docgen-v8

acd6909

github-actions Bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged. label Feb 18, 2026

JCQuintas requested a review from siriwatknp February 19, 2026 16:41

siriwatknp approved these changes Feb 24, 2026

View reviewed changes

github-actions Bot added the PR: out-of-date The pull request has merge conflicts and can't be merged. label Feb 24, 2026

JCQuintas added 6 commits February 24, 2026 09:01

Merge commit '7a59f8a8c6caa672b2705e3f3146f2892fde7364' into docgen-v8

e3c6346

Merge commit 'ab6e743e59454f3f9ab0488aa771cd68c41ed903' into docgen-v8

e0d68da

Merge commit '18a829b00914239709e09e0679ea4de2c0af8dd1' into docgen-v8

525e94f

Merge commit 'fe0e4b4248b0cd8f2d0b2df684b04966f7c7f14f' into docgen-v8

2bb4a9b

Merge commit '6e9f2ab1004a1c3fc5f5760e132db9da67310af1' into docgen-v8

30071a9

Merge commit '0081c48dff63278c95939d223461e0f754ecf39a' into docgen-v8

9da3f78

github-actions Bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged. label Feb 24, 2026

JCQuintas enabled auto-merge (squash) February 24, 2026 12:06

JCQuintas merged commit 600ea84 into mui:master Feb 24, 2026
23 checks passed

brijeshb42 mentioned this pull request Apr 16, 2026

[docs-infra] Fix duplicate JSDoc in proptypes generation for merged declarations #48296

Merged

1 task

brijeshb42 mentioned this pull request Apr 16, 2026

[docs-infra] Fix duplicate JSDoc in proptypes generation #48304

Merged

1 task

Uh oh!

Conversation

JCQuintas commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mui-bot commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Netlify deploy preview

Bundle size report

Uh oh!

JCQuintas commented Jan 27, 2026

Uh oh!

Janpot Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

JCQuintas Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

JCQuintas Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Janpot Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

JCQuintas Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Janpot Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JCQuintas Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Janpot commented Jan 28, 2026

Uh oh!

Janpot commented Jan 28, 2026

Uh oh!

siriwatknp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

JCQuintas commented Jan 26, 2026 •

edited

Loading

mui-bot commented Jan 26, 2026 •

edited

Loading

Janpot Jan 28, 2026 •

edited

Loading