-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A flat carbon-components-react entrypoint is not tree-shakeable #5442
Comments
We're going to proceed with a non-flat entrypoint for the foreseeable future and leverage the |
@joshblack What does this mean for consumers? Do we need to import everything from "carbon-components-react/es/{componentPath}" for tree shaking to work? For large applications this seems like a burden. Also it seems like if importing from "carbon-components-react" imports all of the components combined AND the individual modules. |
Hi there @leximarie! The project is currently set up to be tree-shaken with webpack because of the Here's the result of a build using the stock create-react-app tool along with importing button: Snippet import { Button } from 'carbon-components-react';
// Used in App component |
@joshblack It looks like it works if I am only importing Button (possibly others, but I can't test every component), so are there components that break tree-shaking? For example, I am not using DatePicker anywhere in our application but the DatePicker module is included in the bundle. |
@leximarie it may be that a component being used is dependent on |
While verifying v10.10 over in #5398, we noticed a regression in bundle size when using
carbon-components-react
along with Webpack. Notably, when we were using babel to compile our components then webpack picked up onsideEffects: false
for module file paths and correctly inferred that they had no side effects.In a single entrypoint, we run into a set of problems with assignment expressions. Consider the following situations:
Note: all situations can be run in a Terser sandbox here to verify output
As a result of these situations, we need to update our build process before we can ship a single entrypoint generated by Rollup for our ESM and CJS bundles. We would need to make the following changes:
propTypes
are assigned based on environment (NODE_ENV === 'development'
) so that they are stripped in production buildsunsafe-wrap
optiondefaultProps
Links & Resources
The text was updated successfully, but these errors were encountered: