carbon-components is not amenable to tree-shaking

[s100]

What package(s) are you using?

• carbon-components
• carbon-components-react

Detailed description

Describe in detail the issue you're having.

Bundle sizes involving carbon-components (including when used via carbon-components-react) are a lot larger than I expect them to be because there seems to be no tree-shaking going on in carbon-components.

Create a file entry.js reading as follows:

import { Loading } from 'carbon-components'
console.log(Loading) // don't render, just log

Then at the command line:

npm install carbon-components webpack webpack-cli
npx webpack entry.js --output output1.js --mode production

You'll find output1.js is in the vicinity of 111kB, and at a glance appears to contain the entirety of carbon-components.

Next, open node_modules/carbon-components/package.json and add a property "sideEffects": false here. Save it and go back to the command line.

npx webpack entry.js --output output2.js --mode production

Here, we find that output2.js is more like 11kB, contains only the Loading component and its one or two required modules.

Is this issue related to a specific component?

No.

What did you expect to happen? What happened instead? What would you like to
see changed?

I am not going to suggest that adding "sideEffects": false to carbon-components' package.json is the entire solution here, there's obviously a lot of different externalities and testing to think about...

What version of the Carbon Design System are you using?

[email protected]

[asudoh]

Thanks @s100 for your thoughts and analysis. Need to learn how "sideEffects": false exactly works; My biggest interest is whether it affects only the entry-point, given no imports from the entry-point has side effects whereas some of shipped files (which are not imported from the entry-point) have side effects.

Meanwhile, if you do the following at one of the your project where carbon-components is in the node_modules directory:

> npm i -g rollup @rollup/plugin-node-resolve rollup-plugin-commonjs rollup-plugin-terser
> echo "import { Loading } from 'carbon-components'; console.log('Loading:', Loading);" | rollup --format iife -p @rollup/plugin-node-resolve -p 'commonjs={"include":["node_modules/**"]}' -p terser | gzip -c | wc -c

You'll get:

...
created stdout in 2.4s
   24282

Not on-par to fully-tree-shaken result (due to a 3rd party library not defined as pure), but some improvements. If you replace | gzip -c | wc -c with | pbcopy, paste it to your editor and search for selectorInit:, you'll see (drastically) reduced number of components in the bundle.

[asudoh]

Another ref: https://github.com/carbon-design-system/carbon/blob/v10.11.0/packages/components/tests/pure-modules-test.js

[joshblack]

Duplicate of #4881 I think, agreed that there is definitely room to improve here. Certain dependencies might be unable to be tree-shaken but we can definitely improve what exists out there now.

[s100]

I have discovered that [email protected] has exactly the same issue. If entry.js reads:

import { iconAdd } from 'carbon-icons'
console.log(iconAdd)

then npx webpack entry.js --output output1.js --mode production yields an 88kB bundle containing every single Carbon icon.

If I add "sideEffects": false to carbon-icons' package.json, the result is 1.15kB and contains only the icon I used.

[s100]

Actually, on reflection, it seems that carbon-icons hasn't been updated for two years... So, I think "upgrade to @carbon/icons-react" is an acceptable response to that particular issue. That's what we plan to do. The query with carbon-components remains though.

[tw15egan]

Closing as resolved/dup of #4881, feel free to reopen if you feel that is not the case 🙂