[icons-material] Simplify type declaration in built package.json

[ClementValot]

Hi 👋

The @mui/icons-material package exposes several thousands .d.ts and .d.mts files, which all have the exact same content under a different filename.

This helped uncover a silly edge case with yarn, which will be fixed, but also led me to think of a possible optimization in this package.

Having the wildcard export point to a single file reduces the overall volume of the package, with no loss of information for the type checker. I've run some tests, and from what I know from Typescript's type resolution, this should be a transparent change for the package consumers, and even a small relief for the TS engine :)

Also, the index.d.mts seemed to be entirely unused so that's one fewer big file

• I have followed (at least) the PR section of the contributing guide.

[code-infra-dashboard]

Deploy preview

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

Bundle size

Bundle	Parsed size	Gzip size
@mui/material	0B(0.00%)	0B(0.00%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/private-theming	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

---

Check out the code infra dashboard for more information about this PR.

[ClementValot]

The above Bundle size preview doesn't include icons-material :(
This would be interesting because that's a diff of 21502 fewer files

[ClementValot]

Hmmm the bundle-size-monitor job raises an issue for some moduleResolution but from the looks of it it's just about tinkering with the package.json, I'll have a go at it later today

[mj12albert]

Does this PR have the same goal as #48689 ?

[ClementValot]

Nope, this one only touches the build/ folder and does nothing to the built lib/

[ClementValot]

moduleResolution: node10 proved a bit tricky to support (ugh), so I understand the initial need to have every single MyIcon.d.ts file "physically" present.

Still, I found a standard Typescript solution in typesVersions so that everything - yarn, attw, tsc, and everyone's disk space - is finally happy :)

[ClementValot]

The typesVersion includes a <7.0 which should make everything light up in red the moment the repo moves to TypeScript 7, which is exactly when some discussions, like whether to drop support for node10, should be had

[ClementValot]

Actually mui support for node10 and TS 7 is not mutually exclusive;

Only the tests in @mui-internal/test-module-resolutions will have to be updated, one for TS6xnode10, one for TS6xnode16, and one for TS7xnode16, since TS7 drops node10 support

In the end, the resulting types should still be transparent for the consumers, so I'm happy with where my trick landed 🤞