Material-ui: Typescript definitions for TableCell

Created on 14 Jan 2019  ยท  10Comments  ยท  Source: mui-org/material-ui


@material-ui/core/TableCell/TableCell.d.ts (13,64): Type '"align"' does not satisfy the constraint '"color" | "hidden" | "dir" | "slot" | "style" | "title" | "children" | "defaultChecked" | "defaultValue" | "suppressContentEditableWarning" | "suppressHydrationWarning" | "accessKey" | ... 240 more ... | "scope"'.

  • [x] This is not a v0.x issue.
  • [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior ๐Ÿค”

Current Behavior ๐Ÿ˜ฏ

Steps to Reproduce ๐Ÿ•น


Link:

1.
2.
3.
4.

Context ๐Ÿ”ฆ

Your Environment ๐ŸŒŽ

| Tech | Version |
|--------------|---------|
| Material-UI | v3.8.3 |
| React | 16.4.14 |
| Browser | Chrome |
| TypeScript | 3.2.1 |
| etc. | |

Table typescript

Most helpful comment

If it is possible try to pin all your @types/* packages. It would be IMO way better if no one would bundle their types since semver can't be applied to type declarations because TS itself doesn't follow semver and type declarations are usually behind their actual implementation which means even minor changes can cause breakage.

However it's way easier for us to maintain our types if we have full control over them. Moving them to the DefinitelyTyped monorepo would slow everything related to material-ui down. We try to not rely on new features in @types/react and usually breakage shouldn't happen to often.

I can't really give you a satisfying answer to this issue. If this happens again just look at the @types/* versions we have in yarn.lock and try to reconcile them with your types.

All 10 comments

How do you use TableCell?

This warning doesn't throw on my code, this throw when run app with yarn start, with react-scripts-ts

I need to know what app you are referring to. Please provide a minimal reproducible example.

This seems similar to #14014

Recently updated as well and I'm also getting this simply from an VSCode IDE as an error

see: Screenshot

File is: node_modules/@material-ui/core/TableCell/TableCell.d.ts

I currently removed all usage of TableCell but this still appears

Update: It seems what @LorenzHenk was referring to is there might have been an addition not intended

simply removing the excess from my screenshot to what was added in #14014 seems to work, though not sure if this is the right fix

Could you please provide the output of yarn list --pattern "@types/react"?

@eps1lon I'm not using yarn, what's the npm alternative for this?

EDIT:

npm ls @types/react output

โ”œโ”€โ”ฌ @material-ui/[email protected]
โ”‚ โ””โ”€โ”ฌ @types/[email protected]
โ”‚   โ””โ”€โ”€ @types/[email protected]  deduped
โ”œโ”€โ”€ @types/[email protected]
โ”œโ”€โ”ฌ @types/[email protected]
โ”‚ โ””โ”€โ”€ @types/[email protected]  deduped
โ”œโ”€โ”ฌ @types/[email protected]
โ”‚ โ”œโ”€โ”€ @types/[email protected]  deduped
โ”‚ โ””โ”€โ”ฌ @types/[email protected]
โ”‚   โ””โ”€โ”€ @types/[email protected]  deduped
โ””โ”€โ”ฌ @types/[email protected]
  โ””โ”€โ”€ @types/[email protected]  deduped

You need to upgrade @types/react.
If this is not possible you can add skipLibCheck: true to your tsconfig. This might disable some type checks in your code base though so I would be careful. Upgrade @types/react is recommend although it might cause other issues in your codebase.

@eps1lon I went ahead and tried that when i did the ls and compared it the the material-ui dependencies. looks like it fixed this.

I'm kinda new to the typescript world, any recommendations to mitigate this type of discrepancies?

Is it generally best practice to simply just upgrade relevant type dependencies when upgrading various libs? (in this case material-ui)

If it is possible try to pin all your @types/* packages. It would be IMO way better if no one would bundle their types since semver can't be applied to type declarations because TS itself doesn't follow semver and type declarations are usually behind their actual implementation which means even minor changes can cause breakage.

However it's way easier for us to maintain our types if we have full control over them. Moving them to the DefinitelyTyped monorepo would slow everything related to material-ui down. We try to not rely on new features in @types/react and usually breakage shouldn't happen to often.

I can't really give you a satisfying answer to this issue. If this happens again just look at the @types/* versions we have in yarn.lock and try to reconcile them with your types.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

garygrubb picture garygrubb  ยท  57Comments

nathanmarks picture nathanmarks  ยท  100Comments

aranw picture aranw  ยท  95Comments

HZooly picture HZooly  ยท  63Comments

darkowic picture darkowic  ยท  62Comments