Replies: 20 comments 26 replies
-
Thanks for starting the discussion @joshblack. I can give some perspective from our journey on converting a codebase to typescript. If typescript types live in this repo, I think it makes the most sense to allow the components to benefit form the robustness they provide, by converting underlying components to typescript. Typescript can be adopted piecemeal
type Props = {
direction: string,
onSuccess: () => void,
icon: any
} can evolve to type Props = {
direction: "up" | "down" | "left" | "right",
onSuccess: () => void,
icon: CarbonIcon
} For these reasons I think typescript adoption could be a collective effort- one that slowly and steadily improves over time as code is refactored to typescript. It doesn't have to a be done in a "big-bang" major carbon release. Those of us in IBM that use typescript + carbon have considered contributing to DefinitelyTyped but it's a lost cause because it will always be out of sync with the underlying carbon code. If the carbon team laid the groundwork for typescript support in this repo, I (and I'm sure others) would be happy to help contribute our time. |
Beta Was this translation helpful? Give feedback.
-
I am an open source (non-IBM) user of Carbon and I have contributed some issues and pull requests here and there. My team is transitioning from JavaScript to TypeScript and the types from DefinitelyTyped have mostly been a great help during our migration. We have needed to route around the occasional discrepancy, but it hasn't been a major impediment. That said, we are also some open source components (such as Tearsheet) from Carbon for IBM Products, which doesn't have any type information at all. It's been more challenging to figure out what to do to temporarily work around the lack of formal types there. I'm particularly interested in seeing this library become even more of an accelerator for our work by having types. It's really great to get so much functionality and also to be able to contribute back when we discover improvements that can be made. I know it's probably a challenge for y'all to coordinate, but I wanted to add a different kind of voice to the conversation. Thanks! |
Beta Was this translation helpful? Give feedback.
-
We just upgraded to the v11 version of import fs from 'fs';
import path from 'path';
import carbonIcons from '@carbon/icons-react';
const fileContent = `${Object.keys(carbonIcons).reduce(
(result, iconName) =>
`${result} declare export const ${iconName}: ComponentType;\n`,
`/* this file is generated, recommend adding to prettier and eslint ignore and committing to git. DO NOT EDIT */
declare module '@carbon/icons-react' {
type SizeType = 16 | 20 | 24 | 32;
type ComponentType = React.ForwardRefExoticComponent<
{
size: SizeType | \`\${SizeType}\`;
} & React.RefAttributes<SVGSVGElement>
>;
`
)}\n}`;
fs.writeFileSync(
path.resolve('./src/definitions/carbonIcons.d.ts'),
fileContent
); |
Beta Was this translation helpful? Give feedback.
-
As a long time user of carbon-components-angular, which natively supports Typescript out of necessity, who has just recently taken the plunge into carbon-components-react for a new project within IBM, I can't overstate how many times having a typed component system has saved me from bugs over the years, and I think would be an extremely valuable addition to the carbon-components-react library. While I understand, it's outside the purview of a component library, it opens the possibility for consumers to type the entire interaction chain from network call to rendering thereby catching, at compile time, possible typos that result from changes to a backend. To a full stack developer, that kind of error catching during refactorings is invaluable. I'd echo what @seanlaff had mentioned in that typing doesn't need to immediately be all encompassing. The carbon-angular team would be a probably be a great resource for figuring out an LOE with regards to type maintenance. Our larger concern at the moment is that our current react application is based on the definitely typed |
Beta Was this translation helpful? Give feedback.
-
Just wanted to post a quick update to this discussion 👀 I just added an "Updates" section to the original discussion, this should include a rough timeline of where this discussion is at and what is currently happening. The first update added to this section was a notice around us creating a working group over on Slack for IBMers to join. If you're interested in helping out at all, please join In this group, we'll be starting out with:
If you have any questions, feel free to reach out or leave a comment here! |
Beta Was this translation helpful? Give feedback.
-
I've been waiting for Typescript to be added to carbon and had been told that it will never make it into the roadmap. So great thanks to @joshblack for starting the convo. Carbon is highly adopted. It's the design system IBM uses for its recent products. Typescript is self-documenting. It gives developers a well-defined contracts, an API, to what a component can do. Providing typed interfaces reduces the friction of having to write documentation by hand and greatly improves the developer experience. As others mentioned above, if I don't know how to use something, I'd hit Ctrl/Cmd+Space and get a list of options. Adopting TypescriptHow important is TypeScript integration relative to other efforts?
As a developer, I'd like to have some quality of life updates please. Seeing a sea of red squiggly lines for having to mix Typescript (web framework) and Javascript (Carbon React) together brings me great pain. Which type strategy do we want to follow? I vote for authoring the source in Typescript. The developer who develops the components knows best what the component should offer. Any additional documentation can be added in JSDoc inline with the Typescript code. Adding types later in DefinitelyTyped usually means backtracking through design notes if the same developer is to write the types. If not, then the type writer would have to reach out to the original developer for the meaning behind a variable. You get the whole "who's going to maintain the types?" and "why are we doing duplicated work?" type questions. How long would this process take? This is like asking how long is a piece of string. How long does it take you to decipher your old code and add in types? Have the developers ever worked with Typescript before? Would authoring our source in TypeScript prevent bugs that we typically encounter? Same argument as above - the developer developing the component benefits from type checking. Carbon is highly adopted. It's the design system IBM uses for its recent products. Hopefully, having the core Carbon team adopting Typescript would inspire/force downstream IBM teams to also adopt Typescript in their Carbon components. Most of IBM components I've used are lightly documented. I had to spend hours figuring out what settings are available and scour through examples (if there were any) to learn how to use a component. Offering Typescript improves the end developer experience of using Carbon in their projects. |
Beta Was this translation helpful? Give feedback.
-
Monday, May 23rd, 2022Below is the agenda for the initial Working Group meeting. This post will also be updated by me to include notes from the session, including next steps or key decisions. Agenda
Understanding the as-is
Understanding the to-beAt a high level, the decision for TypeScript types and Carbon boils down to either authoring the types alongside the source or authoring in DefinitelyTyped. This can be further broken down into:
Package ecosystem
Challenges or unknowns
As maintainers, will you need to update the definition twice (once in TS, once in propTypes) or is there a way to automatically keep them in sync?
Incremental approach It may be possible for us to find ways to incrementally introduce TypeScript into the monorepo, starting with icons due to #11317. This would allow us to adopt it for a subset of packages ( Similarly, we could try and author the definition files in the source code without changing the underlying source code to TS (yet). Over time, the idea would be to shift types from being written manually to coming from the underlying source code. To the end-user, there should be no noticeable impact (hopefully). This would allow TS users to adopt sooner and would help with contributions to the typing files themselves as users would be contributing to the project directly. Discussion, Q&A |
Beta Was this translation helpful? Give feedback.
-
I have used |
Beta Was this translation helpful? Give feedback.
-
Monday, June 6th 2022This is the second meeting of the TypeScript Working Group. Agenda
PlaybackOverall, I believe that the team is receptive to trying this out and seeing how it can improve the experience of authoring and using Carbon. There were some concerns or questions raised, including:
Initial TypeScript Pull RequestLink: #11533 Feedback:
Contribution processWhat would it look like for people wanting to get involved? How do we want to self-organize? How should we structure our work to make it easy to iterate on ideas? Next stepsWhat does a good first deliverable for this group look like? Questions
Q&A |
Beta Was this translation helpful? Give feedback.
-
Monday, June 27th, 2022Agenda
Pending action itemsFor members who have volunteered their time to help out, we have an official team on GitHub that youc an join: https://github.com/orgs/carbon-design-system/teams/wg-typescript You should have received an invite for this team if you shared your GitHub username on Slack, if you have not yet received an invite or need an updated one let me know! Monorepo overviewThis section will be a brief overview of the monorepo, its structure, and common tasks you may need to perform when working within it. Storybook migrationWe currently have the following issue in scope for the working group: #11587 This time slot is to play back where that workstream is currently at and see if there is any additional participation from the WG that could help. move it forward. |
Beta Was this translation helpful? Give feedback.
-
@joshblack any updates on this? Also can't access the team you mentioned above |
Beta Was this translation helpful? Give feedback.
-
Tuesday, August 23rd, 2022Agenda
New primary contact@tay1orjones 👋 😃 If you're interested in helping to coordiate the working group, please let me know. This could include:
Pending action itemsFor members who have volunteered their time to help out, we have an official team on GitHub that you can join: https://github.com/orgs/carbon-design-system/teams/wg-typescript You should have received an invite for this team if you shared your GitHub username on Slack, if you have not yet received an invite or need an updated one let me know! External contributorsWe'll be setting up a channel on our discord for external contributors. We'll post updates there in addition to this discussion. In the future, our check ins can include those who are in the discord channel - please DM me an email to add you to the invite. Storybook migrationWe currently have the following issue in scope for the working group: #11587 This time slot is to play back
Monorepo pull request overviewThis section will be a brief overview of the pull request process for the monorepo. |
Beta Was this translation helpful? Give feedback.
-
I've created the Also the PR laying the groundwork for adding types is up! #12000 |
Beta Was this translation helpful? Give feedback.
-
I am a heavy user of Typescript and Carbon. Unfortunately if Carbon 11 does not support typescript, we can not upgrade our repos to take advantage of the other quality of life updates in 11. Upgrading without typescript would be a significant quality of life decrease overall. |
Beta Was this translation helpful? Give feedback.
-
However, thank you for building carbon! It's a gamechanger. |
Beta Was this translation helpful? Give feedback.
-
When do you think that TS can be implemented in carbon 11? |
Beta Was this translation helpful? Give feedback.
-
Status UpdateThe foundations of two different approaches to providing types are up in PRs right now for consideration:
A huge thanks goes out to @mbarrer for this work! 🙏 Feedback on these two approaches would be appreciated and can be placed in the thread of this message and/or on the PRs themselves. Approach 1This is the initial planned strategy discussed above. Definition files are moved over from DT and updated to match the current spec. The definition files live in each components' folder, are maintained separately from the component source, and are included in the package. The storybook config is updated and stories are typed as a way to validate the types. Approach 2The second approach is a more straightforward refactor including a typed interface in the component source. This has some benefits over the first approach, largely that the storybook config does not change, story files need not be typed, and the types themselves live in the same file as the component source. Next steps
As always, we'll provide updates in this discussion along the way. |
Beta Was this translation helpful? Give feedback.
-
Status update: call for contributions! ✨Hi everyone! I just want to post an update on the overall status of the effort towards TypeScript support in This means we can now begin the work to add component types to the repository. This will be a community effort. We've organized all the work to be done within an umbrella issue with children issues for each component. For anyone interested in helping out, here's a high level of how to get started:
With all this in place, we're so excited for this community effort to really push forward in 2023! Happy typing, and thanks to everyone who has pitched in so far to get this to where it’s at today! 🙏 |
Beta Was this translation helpful? Give feedback.
-
What is the status of this? |
Beta Was this translation helpful? Give feedback.
-
I know that most of the efforts here have been spent on adding types to components thus far; however, I noticed in v11 there are now javascript exports for the "elements" packages, such as color, layout, etc. Can we expect those to be typed at some point? Thanks! |
Beta Was this translation helpful? Give feedback.
-
This is an umbrella discussion around bringing TypeScript to Carbon, specifically to
@carbon/react
but could be included in all of our packages that ship JavaScript. This will be a living discussion that will be updated over time.Updates
August 2023 🎶 We're halfway there 🎶
Actually we're past halfway:
Current status can be found in the issue:
@carbon/react
components #12513The same info can be found in the TypeScript Adoption project. It contains an insights chart that shows progress over time.
Click to expand previous updates
January 2023
The effort to add types to
@carbon/react
is now underway. See the announcement below for detailsMay 20th, 2022
There is a kick-off meeting for the working group on May 23rd, 2022. I will be capturing notes and sharing them below. The intent of this meeting is to:
April 18th, 2022
A Slack channel was created for a TypeScript working group for IBMers, if you're interested in helping out with this workstream please join:
#carbon-wg-typescript
.We are currently investigating the as-is, overall design, and discrete, incremental deliverables that we can accomplish as a group.
Overview
Currently, teams who use TypeScript and Carbon will have types defined either through the community-owned
@types/carbon-components-react
or define them manually. This experience is not currently ideal because there is a chance that these types can get out of sync with the code shipped in the latest release onnpm
.In order to improve this experience, the team has several ways that we can address this issue:
npm
packages, either through:*.d.ts
fileQuestions
*.d.ts
fileNext steps
Our team is currently underway shipping our v11 release in March. Starting in Q2, we'll be working towards migration but will begin taking on new work. In particular, our focus will likely be on new components, testing (specifically visual regression testing), and documentation through Storybook and on our website.
However, if the consensus is that we need to ship TypeScript bindings then we really would like to deliver on that. In the interim, here are some of the open questions that we would like to address:
propTypes
Links & Resources
Beta Was this translation helpful? Give feedback.
All reactions