Compound component (e.g., Form.Group, SearchField.Advanced) exports include entire module in Webpack bundles

[ochavarria2u]

Hello team, making some investigation I found that some of your imports bundles the entire lib, and the tree shacking is not working. Here's an example of search vs container.

|Search field:

• 

• 

Container:

• 

• 

I already validated this with @adamstankiewicz, so please let me know if there's anything I can do in order to help with this issue.

[adamstankiewicz]

Thanks for the report of this issue, @ochavarria2u!

We'll need to decide what we want to do to mitigate these bundle size impacts across Paragon's consuming repos in a reasonable way. For example, is there any workaround to keep compound components (Form.Group) still functional with tree shaking? Do we have standalone components exported for all compound components that be migrated over to? Is there a CLI tool we could expose to consumers to auto-migrate compound components to their associated standalone components (e.g., Form.Group ▶️ FormGroup)?

[viktorrusakov]

Hey, @ochavarria2u, thanks for reporting this!

The root problem was that our icons package did not support tree-shaking at all, which resulted in all of the icons being included into the initial bundle if your code used at least one of the icons. That's what happened in your first example - SearchField uses couple of icons internally which led to including all of the icons into the initial bundle. Container on the other hand does not use any icons, so only this component got into the bundle.

Note however that this only caused size problems for the initial bundle size (Stat size on the screenshots), but after minification process all of the redundant icons were removed and did not get into the final bundle provided you built your project with the help of frontend-build (you can see it by the Parsed size and Gzipped size). You can read more on how that happened in the comments to the PR that adds tree-shaking to icons package. The fix was released in v20.45.2 of Paragon and it should drastically reduce Stat size of you bundles.

I'm not sure why your first example reports 0B for parsed and gzipped sizes though, I believe that means that none of paragon code got into the final bundle, which is really strange. When I tried to reproduce your example this is what I got

Could you maybe provide a bit more context on the first example, e.g. how did you use TestParagonLib component in the code and what script you used to build the application?

[ochavarria2u]

Hi @viktorrusakov thanks for the fix, I've been fetching the reports and it seems that the bundle size got reduced by 150mb. Checking our reports it seems that the parsed size and gzipped size is still 0. I belief this is the reason why.

I'm seeing that some of the parents aren't supporting treeshake so we can only do compound components, do you have plans on doing it ? Here's some componenets I've identify that could use the change.

import { SearchField } from '@edx/paragon';
import { Form } from '@edx/paragon';
import { Collapsible } from '@edx/paragon'; // Needs to implement treeshake
import { Dropdown } from '@edx/paragon'; // Needs to implement treeshake
import { ModalDialog } from '@edx/paragon'; // Needs to implement treeshake
import { Card } from '@edx/paragon'; // Needs to implement treeshake

FYI - Here's how we use the reports:
...(process.env.BUNDLE_REPORT ? [ { resolve: 'gatsby-plugin-webpack-bundle-analyser-v2', options: { devMode: true, analyzerMode: 'static', openAnalyzer: true, }, }, 'gatsby-plugin-perf-budgets', ] : []),

[viktorrusakov]

@ochavarria2u I don't think these component would affect the bundle very much as they only include related compound components (which shouldn't take too much space) into the bundle and not the whole Paragon. However, I understand that it is still an issue and we do plan to fix them.

I've created a separate issue #2464 to track progress on migrating off of compound components in Paragon. I'm pretty sure there is no way to support tree-shaking for them, so we just have to remove them and instead only use standalone components. I'm not sure when this will be done though, I'd like to hear @adamstankiewicz's thoughts here also.

[adamstankiewicz]

@ochavarria2u @viktorrusakov I agree, it appears that compound components (e.g., Form.Group, SearchField.Advanced) can not support tree-shaking, unfortunately. Thanks Viktor for filing #2464.

I think the first step here should be to evaluate whether all Paragon's compound components have an associated standalone component export (e.g., If we have Form.Group, FormGroup should also be exported. Assuming we do export all compound components as standalone components today, @ochavarria2u you should be able to migrate off the compound components in your repo to mitigate the tree shaking concern. Though as Viktor mentioned, these components shouldn't really take up too, too much space although we should still definitely optimize it.

Then, tackling what's proposed in #2464 makes sense. We should definitely deprecate the compound components (perhaps even with a legit DEPR ticket, which I'd be happy to file) first with adequate warning for consumers. @viktorrusakov I'll add some thoughts to this effect to #2464.

tl;dr; For the purpose of this issue, we should confirm that all compound components do indeed have an associated standalone components exported already to ensure consumers have a path forward today to mitigate these concerns, and perhaps update the Paragon README about tree shaking to mention lack of support for it with compound components: https://github.com/openedx/paragon#treeshaking

[brian-smith-tcril]

Moving conversation to #2464