Pulls in redundant, clashing `carbon-components` CSS

I am submitting a…

• Feature request
• Design defect
• Source code defect
• Demo/documentation defect
• Other

charts version:

@carbon/charts@0.41.103 or thereabouts (precise version not known, sorry)

Issue description

It looks as if @carbon/charts has a pinned dependency on an old version of Carbon, carbon-components@10.40.0. This clashes with the most recent version of Carbon, which is 10.41.x or thereabouts.

Under normal circumstances, having two versions of the same dependency library in play at once wouldn’t cause too much trouble. However, in this case carbon-components is a UI library with its own associated CSS. These two sets of CSS both apply to the same CSS classes and so they (1) create a great deal of redundancy in our output CSS bundle and (2) clash with one another because they disagree slightly about the structure of the UI components they’re trying to style.

Steps to produce the issue

I have a basic webpack build with an index.js which simply loads an index.css, which reads as follows:

@import '~carbon-components/scss/globals/scss/styles';
@import '~@carbon/charts/styles/styles';

When I run the build and inspect the output CSS bundle…

Current behavior

…I see two distinct blocks of CSS which, for example, alter the rendering of .bx--modal-container, which is part of Carbon’s <Modal> component. One of these blocks comes from our application’s version of carbon-components, and one comes from @carbon/charts’s version of carbon-components.

Expected behavior

• I would expect @carbon/charts to allow a more flexible range of versions of carbon-components, ^10.40.0 for example.
• I would also not expect @carbon/charts’s CSS to contain redundant copies of some of carbon-components’s CSS. I would expect to be required to load that CSS once, myself. Imagine if multiple different Carbon-related UI libraries did the same thing… we would end up with two or three or four full copies of Carbon’s CSS. In fact, that is exactly the issue we are having right now! @carbon/charts is just one of several UI libraries where I am trying to get this issue fixed!

Screenshot or recording

Because of this clashing CSS, we see puzzling rendering errors like this:

See how the margins on the modal are too narrow.

[s100]

My preferred model for consuming @carbon/charts would be something like this:

• First, change the carbon-components dependency to ^10.40.0 or something like that. The way you have it currently, we end up needing to pin to 10.40.0 just like you have, which is problematic when other UI component libraries we depend on have moved forward and require more recent Carbon versions. In general Carbon’s DOM structure and CSS can be relied upon not to change too much, so this should not cause problems. And, it shouldn’t be necessary to rely on that exact structure anyway. If there are other concerns here which I’m not aware of, I’d be interested to hear them.

• Second, figure out this duplication issue.

  • Make it so that @carbon/charts’s CSS stops incorporating carbon-components’s CSS. @carbon/charts can still rely on carbon-components’s CSS to have been loaded, but will no longer actually include any of it as part of its distribution.
  • In the @carbon/charts README, document exactly how to load Carbon’s CSS first, and which specific parts are required (if not the entirety of Carbon’s CSS). This documentation would probably recommend doing the following:

@import '~carbon-components/scss/globals/scss/styles';
@import '~@carbon/charts/styles/styles';

As this would be a breaking change, bumping the minor version of @carbon/charts would also be required.

[s100]

Are you saying that you’ve copied Carbon’s HTML source for their modal and overflow menu components into @carbon/charts’s source? And because you’ve copied some of the HTML from that specific version of Carbon, you also need to bundle the CSS from that specific version of Carbon? I have been looking in the code to try to see for myself and this certainly looks like what I’m describing… If so, then all I can say is that I’m fairly sure carbon-components isn’t intended to be consumed in this way, for all of the reasons that I’ve been describing. At this point, the modal is essentially your own original component which just happens to closely resemble Carbon’s. Unfortunately, as developers, you have the worst of both worlds - all the hassle of maintaining your own UI component instead of relying on a third party to do it for you, but none of the freedom in markup/rendering/styling which would come with that choice.

I don’t know what it’s like maintaining a package which supports many different UI frameworks at once, we use React only… But surely there has to be a way to do this where you don’t end up pinned to a specific patch of Carbon, and bundling that specific patch’s CSS along with the package.

(Incidentally, isn’t this kind of thing vulnerable to XSS attacks?)