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

sys13 picture sys13  ยท  3Comments

mb-copart picture mb-copart  ยท  3Comments

activatedgeek picture activatedgeek  ยท  3Comments

TimoRuetten picture TimoRuetten  ยท  3Comments

rbozan picture rbozan  ยท  3Comments