Typescript definitions

I think it would be really cool if we could start writing (or generating) some typings for this project.

Its quite frustrating having to leave my editor everytime i need to check what props are available.

PropTypes are great for runtime analysis, but most tools cannot statically parse prop types. Editors like VSCode use TS defintion files to provide “intellisense” to users.

Libraries like material-ui have fully typed components, have a look at what VSCode is able to provide me for their Button component

But just because we are using JS does not mean we need to sacrifice static typing for our consumers - .d.ts files can be used to export type defintions for JS libraries

This is something that I would love to see implemented to improve the developer experience with carbon!

Keep up the great work!

[daka1510]

Totally agree that adding type definitions to Carbon would be a great move. I worked for 2 years with Carbon within IBM. Tried using https://www.npmjs.com/package/@types/carbon-components-react but stopped because those type definitions were not always in sync with the actual code.

Similarly, I think there is hesitation with respect to what maintenance means for types and if we would need to respect semver both for package versions and types.

My take: if efforts are taken to provide type declarations, include them in the source package itself.

[seanlaff]

Hi @joshblack we’re a team inside IBM and would like to revisit this issue.

Typescript has a been a lifesaver for us at scale. The types catch a host of different errors before any code gets pushed, and the autocompletions that IDEs provide end up being a huge timesaver with regards to developer-experience.

Given the carbon team manually writes propType definitions, I understand your hesitation to write even more definitions by hand. I like @dan-cooke’s suggestion of generating typescript types from propTypes as a quick shim, but propTypes are not that expressive (i.e you can declare a prop is a function… but cant require it matches a certain signature). Thus, the typescript types generated this way would be lackluster (but surely better than nothing).

Stepping back, a better approach might be to have carbon be typescript native, increasingly the resiliency of carbon itself as well as downstream apps. Additionally, we could generate propTypes from the typescript types for non-typescript consumers (since type accuracy is not lost when going from ts->propTypes, while the reverse is not true). There are a few way to do this, such as via babel-plugin https://github.com/milesj/babel-plugin-typescript-to-proptypes.

In any case, it feels like typescript has reached a level of popularity that I think the typings deserve some thinking.