Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Pulls in redundant, clashing `carbon-components` CSS

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:11 (10 by maintainers)

github_iconTop GitHub Comments

s100commented, Aug 13, 2021

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.

s100commented, Oct 1, 2021

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?)

Read more comments on GitHub >

github_iconTop Results From Across the Web

Guide - Carbon Design System
This guide helps you update your project to Carbon v11. It is broken into sections based on packages that you are using in...
Read more >
4. Creating components - Carbon Design System
Welcome to Carbon! This tutorial will guide you in creating a React app with the Carbon Design System.
Read more >
Frameworks - Carbon Design System
The library provides front-end developers & engineers a collection of reusable HTML and SCSS partials to build websites and user interfaces.
Read more >
Developers - Carbon Design System
The import system removes duplicate dependencies, so shared dependencies between components will not create extra CSS.
Read more >
Bugs and requests - Carbon Design System
Here are detailed instructions for forking the repo and opening a pull request. Requests for comment. For changes that are larger in scale,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found