Investigate tree-shaking opportunities for carbon-components

[joshblack]

We use only a small set of functionality from carbon-components in carbon-components-react, specifically settings.prefix, but unfortunately are unable to tree-shake unused parts of vanilla components. This issue is to investigate why and address why these modules are unable to be DCE'd.

• Additionally evaluate if there could be a carbon icons subfolder where we reexport from there so carbon icons is more tree shakable

[theskillwithin]

any news on this one?

[joshblack]

Hi @theskillwithin! 👋

In our next major release, we will remove the dependency on carbon-components from carbon-components-react which should address this 😄 In the interim, we added support for sideEffects in carbon-components which also helps with dropping unused dependencies!

[enagorny]

@joshblack is there an issue to track progress of removing carbon-components?

we will remove the dependency on carbon-components from carbon-components-react

[joshblack]

Hey there @enagorny! Currently, this is tracking for our 2021 Release: https://medium.com/carbondesign/whats-coming-to-carbon-in-2021-39a4c7d1762a We don't have an umbrella issue yet for this release but when we finalize it we'll make sure it's a pinned issue 👍

[jayarjo]

Does this mean that for example if we use just one component from Carbon, the rest won't be auto-included either?

[joshblack]

@jayarjo by default, this should be the case for carbon-components-react. Often times if you are bringing in every component, then there is an import to carbon-components-react/lib/components/* somewhere which is causing the bundle to load CommonJS modules.

This issue originally came up when vanilla JS files from carbon-components were being included in the bundle because of our usage of settings.prefix. Thankfully this should no longer be the case, as well, but we will still move forward with dropping carbon-components from carbon-components-react in the future 😄

Hope this helps!