Add carbon and theming to core package

[ericabr]

Core package:

• We need to add carbon 10 in a way it can be required by other packages
  https://github.com/carbon-design-system/carbon/blob/master/packages/react
• Add theming to be picked up by other packages https://github.com/carbon-design-system/carbon/tree/master/packages/themes

[SimonFinney]

Very cool! Another thing we could consider is adding a theme switcher to the Storybook to enable switching between dark and light themes - @carbon-design-system/ibm-cloud-paks thoughts on this and what the default theme might be?

[ericabr]

Yes, I love that Idea! I think the default theme should be the dark theme since it looks like we are headed that way.

[matthew-chirgwin]

Hi! I missed the last interlock (I will be able join today however), but is there a description of all the packages, and what the architecture/relationship they have to each other I could catch up on? The reason I ask (and I more than likely have the wrong end of the stick!) is if all packages consume core, that would default everyone to the same version of Carbon/the theme used say. Could that cause issues (one package wanting version X, others wanting Y for example)?

[ericabr]

I think for now, the other packages don't have to consume core. In the long run, we want all of the other packages to consume core once we are more aligned. Core will be the driving force of the version of carbon we should all try and keep in line with once we actually start pointing towards it.
Today, the packages being hosted here are:

• Automation
• CD & AI
• Security
• Bedrock services ->common services

I think we should add these to the common README for others awareness.

[matthew-chirgwin]

Now I have caught up, just wanted to share my thoughts on what I would suggest a core package could do going forward:

• I see a core package being mainly helpful utility pieces - common test helpers, build configuration, linting, common storybook pieces and so on
  • With the intent that teams migrate to using these helpers and so on in their current code - in turn, meaning we all converge on a common style/approach
  • To aid this convergence, documentation around approach, rules of engagement and best practise should be written to aid conversion, as well as guide new implementation
• It should contain useful/reusable assets - icons, images, etc
• Rather than depending/exporting carbon - it defines/exports the version of carbon (carbon-components-react, carbon-icons, carbon-components) we all ‘should’ use in our own package.json (expected to be spread say into the dependancy section)
  • Allows flexibility for consumers to use alternative versions when required - we will have cases where package A needs a fix, but B doesn’t want to change due to a code freeze etc

Theming is an interesting bit. In my experience in the CDAI package, we have had a number of discussions (and contention) around having a set theme that all consumers must use. In our case the designs given to engineering did not account for some of the technical imitations around Carbon components and their theme-ability. This happens typically (but was not limited to) where we need Carbon component X in a light variant, but such a thing does not exist.

This is one of the many examples where deviation from Carbon will be required in its current form (and one of the reasons I err when suggesting set values in a core package - there will be cases where this will not work for all).

What I would suggest we do (and again, documentation in the core package could guide/define this) is full use of Carbon tokens and mixins for colour, typography, spacing and layout etc in all styling. This means if overrides are needed (if any), they are in this case theme agnostic, and consumable (if needed) by everyone with minimal changes. These overrides should be contributed to the core package for others to use if needed - if we need to diviate, we all should do so using the same code. By doing this, the setting of the theme can then be the responsibility of the consumer of the package (ie CDAI for instance). By doing this, theming then isn’t a responsibility of the core package, but as a group of packages, we can support any theme.

[lee-chase]

Raised carbon-design-system/carbon#6828

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.